December 2016 - Pharo-dev - lists.pharo.org

[pharo-project/pharo-core]

by GitHub

Branch: refs/tags/60318 Home: https://github.com/pharo-project/pharo-core

Dec. 6, 2016

[pharo-project/pharo-core] 55be1a: 60318

by GitHub

Branch: refs/heads/6.0 Home: https://github.com/pharo-project/pharo-core Commit: 55be1a1eac6fb945dfa11771de5fcbb523f56034 https://github.com/pharo-project/pharo-core/commit/55be1a1eac6fb945dfa11771… Author: Jenkins Build Server <board(a)pharo-project.org> Date: 2016-12-06 (Tue, 06 Dec 2016) Changed paths: M Komitter.package/KomitterUI.class/instance/api/newKomitFor_.st A Reflectivity-Tests.package/ReflectivityControlTest.class/instance/tests - conditions/testConditionDisableEnableNoArguments.st A Reflectivity-Tests.package/ReflectivityControlTest.class/instance/tests - conditions/testConditionDisableEnableWithArguments.st M Reflectivity-Tests.package/ReflectivityControlTest.class/instance/tests - conditions/testConditionWithArgument.st M Reflectivity.package/HookGenerator.class/instance/ast manipulation/wrapCondition_link_.st M Reflectivity.package/RFASTTranslator.class/instance/reflectivity/emitPreamble_.st M Reflectivity.package/RFCondition.class/instance/accessing/valueSelector.st A Reflectivity.package/RFCondition.class/instance/evaluating/cull_.st R ScriptLoader60.package/ScriptLoader.class/instance/pharo - scripts/script60317.st A ScriptLoader60.package/ScriptLoader.class/instance/pharo - scripts/script60318.st R ScriptLoader60.package/ScriptLoader.class/instance/pharo - updates/update60317.st A ScriptLoader60.package/ScriptLoader.class/instance/pharo - updates/update60318.st M ScriptLoader60.package/ScriptLoader.class/instance/public/commentForCurrentUpdate.st M Traits.package/TClass.class/instance/class variables/addClassVariable_.st A Traits.package/TClass.class/instance/class variables/anyUserOfClassVarNamed_.st M Traits.package/TClass.class/instance/class variables/removeClassVarNamed_interactive_.st Log Message: ----------- 60318 19425 Stack underflow with meta links on message nodes https://pharo.fogbugz.com/f/cases/19425 19284 MetaLink: re-enabling a condition with arguments can not be executed anymore https://pharo.fogbugz.com/f/cases/19284 18994 Komitter should stringify the commit message (breaks GitFileTree) https://pharo.fogbugz.com/f/cases/18994 19421 Failing test: WeakAnnouncerTest>>#testNoDeadWeakSubscriptions https://pharo.fogbugz.com/f/cases/19421 19415 classVariableAdd and classVariableRemove not announce ClassModificationApplied event https://pharo.fogbugz.com/f/cases/19415 http://files.pharo.org/image/60/60318.zip

Dec. 6, 2016

Re: [Pharo-dev] Generate accessors refactoring

by Denis Kudriashov

2016-12-06 15:09 GMT+01:00 Yuriy Tymchuk <yuriy.tymchuk(a)me.com>: > It shouldnât be too intelligent. Keep the default behavior, and for each > method add a 3-state checkbox: create (default), skip, force (override). > Also having a usage recorder would be nice to know if developers are > actually checking the other state more often than the default one. For me it is too intelligent now because it is tried to create new version of accessors instead of existing one. But simple logic should just analyze method name and if accessor already exists it should skip it

Dec. 6, 2016

Re: [Pharo-dev] Generate accessors refactoring

by Yuriy Tymchuk

It shouldnât be too intelligent. Keep the default behavior, and for each method add a 3-state checkbox: create (default), skip, force (override). Also having a usage recorder would be nice to know if developers are actually checking the other state more often than the default one. Uko > On 6 Dec 2016, at 13:03, Thierry Goubier <thierry.goubier(a)gmail.com> wrote: > > > > 2016-12-06 11:34 GMT+01:00 Denis Kudriashov <dionisiydk(a)gmail.com <mailto:dionisiydk@gmail.com>>: > > 2016-12-06 11:28 GMT+01:00 Yuriy Tymchuk <yuriy.tymchuk(a)me.com <mailto:yuriy.tymchuk@me.com>>: > Additionally it was annoying if a superclass has a method with the same name. For example if you have a name var and you create accessors Iâd like to have actually a ânameâ getter and not âname1â > > Yes > > > If you start to make it so intelligent it requires half a dozen click to generate a simple accessor, then people will stop using the refactoring and write the code by hand... > > Thierry > >

Dec. 6, 2016

Re: [Pharo-dev] OCASTTranslator forValue/forEffect

by Marcus Denker

> >> >> @Marcus, >> can we *always* use the valueTranslator when visiting a link preamble ? >> (I tried this, the above method now works, and all tests are green, but I am not sure if this is the right solution). >> > > Yes, I think so. The idea is that the preamble is just about stack manipulation, so we actually are not interested > in e.g. popping off the result after a send where the value is not needed. > > I will commit a slide with the fix. > https://pharo.fogbugz.com/f/cases/19425/Stack-underflow-with-meta-links-on-… <https://pharo.fogbugz.com/f/cases/19425/Stack-underflow-with-meta-links-on-…> Marcus

Dec. 6, 2016

Re: [Pharo-dev] Generate accessors refactoring

by Thierry Goubier

2016-12-06 11:34 GMT+01:00 Denis Kudriashov <dionisiydk(a)gmail.com>: > > 2016-12-06 11:28 GMT+01:00 Yuriy Tymchuk <yuriy.tymchuk(a)me.com>: > >> Additionally it was annoying if a superclass has a method with the same >> name. For example if you have a name var and you create accessors Iâd like >> to have actually a ânameâ getter and not âname1â > > > Yes > > If you start to make it so intelligent it requires half a dozen click to generate a simple accessor, then people will stop using the refactoring and write the code by hand... Thierry

Dec. 6, 2016

Re: [Pharo-dev] Generate accessors refactoring

by Denis Kudriashov

2016-12-06 11:28 GMT+01:00 Yuriy Tymchuk <yuriy.tymchuk(a)me.com>: > Additionally it was annoying if a superclass has a method with the same > name. For example if you have a name var and you create accessors Iâd like > to have actually a ânameâ getter and not âname1â Yes

Dec. 6, 2016

Re: [Pharo-dev] Generate accessors refactoring

by Yuriy Tymchuk

Additionally it was annoying if a superclass has a method with the same name. For example if you have a name var and you create accessors Iâd like to have actually a ânameâ getter and not âname1â Uko > On 6 Dec 2016, at 11:16, Nicolai Hess <nicolaihess(a)gmail.com> wrote: > > > > 2016-12-06 11:09 GMT+01:00 Denis Kudriashov <dionisiydk(a)gmail.com <mailto:dionisiydk@gmail.com>>: > Hi. > > There is very annoying logic of accessors refactoring. > For example imaging your class already has getter for variable #myInstVar but with some extra code instead of simple return. For example it could be lazy initialization: > > MyClass>>myInstVar > ^myInstVar ifNil: [#someValue] > > In that case accessors generator will suggest you new getter method #myInstVar1. > I really doubt that anybody accept generation of such method. > I always remove it from changes list which is very annoying. > > Am I alone about it? Can we remove this logic? > > Best regards, > Denis > > 18880 <https://pharo.fogbugz.com/f/cases/18880/Autogenerating-accessors-should-be-…> Autogenerating accessors should be less naive

Dec. 6, 2016

Re: [Pharo-dev] Generate accessors refactoring

by Nicolai Hess

2016-12-06 11:09 GMT+01:00 Denis Kudriashov <dionisiydk(a)gmail.com>: > Hi. > > There is very annoying logic of accessors refactoring. > For example imaging your class already has getter for variable #myInstVar > but with some extra code instead of simple return. For example it could be > lazy initialization: > > > MyClass>>myInstVar > ^myInstVar ifNil: [#someValue] > > > In that case accessors generator will suggest you new getter method > #myInstVar*1. * > I really doubt that anybody accept generation of such method. > I always remove it from changes list which is very annoying. > > Am I alone about it? Can we remove this logic? > > Best regards, > Denis > 18880 <https://pharo.fogbugz.com/f/cases/18880/Autogenerating-accessors-should-be-…> Autogenerating accessors should be less naive

Dec. 6, 2016

Re: [Pharo-dev] Generate accessors refactoring

by Aliaksei Syrel

+1 super annoying! On Dec 6, 2016 11:10, "Denis Kudriashov" <dionisiydk(a)gmail.com> wrote: > Hi. > > There is very annoying logic of accessors refactoring. > For example imaging your class already has getter for variable #myInstVar > but with some extra code instead of simple return. For example it could be > lazy initialization: > > > MyClass>>myInstVar > ^myInstVar ifNil: [#someValue] > > > In that case accessors generator will suggest you new getter method > #myInstVar*1. * > I really doubt that anybody accept generation of such method. > I always remove it from changes list which is very annoying. > > Am I alone about it? Can we remove this logic? > > Best regards, > Denis >

Dec. 6, 2016