- Pharo-dev - lists.pharo.org

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

Generate accessors refactoring

by Denis Kudriashov

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

Re: [Pharo-dev] OCASTTranslator forValue/forEffect

by Marcus Denker

> On 5 Dec 2016, at 05:36, Nicolai Hess <nicolaihess(a)gmail.com> wrote: > > > > 2016-12-05 8:51 GMT+01:00 Nicolas Cellier <nicolas.cellier.aka.nice(a)gmail.com <mailto:nicolas.cellier.aka.nice@gmail.com>>: > Translate AST to byte codes? > > (For opal, this first creates the intermediate representation (IR), but yes translating from AST to (finally) byte codes) > > One for the case when we don't care of the result (we will pop it off the stack), we just want the effect. > > Ok. > > The other case when we want to keep the resulting value on the stack. > > Who decides which to use, when do I know that I need to use, the effect translator only or the value translator? > Sorry for not answering, I was travelling and now catching up with emails. The decision to visit âfor effect onlyâ or âfor valueâ is taken by the visitor depending on what part of the ast it is visiting. > > @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. Marcus

Dec. 5, 2016

[pharo-project/pharo-core] 3a3e92: 60317

by GitHub

Branch: refs/heads/6.0 Home: https://github.com/pharo-project/pharo-core Commit: 3a3e9257057cd07deb1e5165889379a4c62e28d1 https://github.com/pharo-project/pharo-core/commit/3a3e9257057cd07deb1e5165… Author: Jenkins Build Server <board(a)pharo-project.org> Date: 2016-12-05 (Mon, 05 Dec 2016) Changed paths: M Kernel.package/ClassOrganization.class/instance/backward compatibility/classify_under_suppressIfDefault_.st R Kernel.package/ProtocolOrganizer.class/instance/protocol/protocolOfSelector_.st M RPackage-Core.package/RPackage.class/instance/class tags/basicRemoveTag_.st M RPackage-Core.package/RPackageTag.class/instance/accessing/removeFromPackage.st R ScriptLoader60.package/ScriptLoader.class/instance/pharo - scripts/script60316.st A ScriptLoader60.package/ScriptLoader.class/instance/pharo - scripts/script60317.st R ScriptLoader60.package/ScriptLoader.class/instance/pharo - updates/update60316.st A ScriptLoader60.package/ScriptLoader.class/instance/pharo - updates/update60317.st M ScriptLoader60.package/ScriptLoader.class/instance/public/commentForCurrentUpdate.st M Spec-Tools.package/MessageBrowser.class/instance/testing/buildHierarchyForMessages_.st Log Message: ----------- 60317 19409 ClassTagRemoved is not announced when packageTag is removed when it becomes empty after class is moved https://pharo.fogbugz.com/f/cases/19409 19319 Editing methods in filtered MessageBrowser raise error https://pharo.fogbugz.com/f/cases/19319 19417 Loading new trait methods put them into unclassified category of user classes https://pharo.fogbugz.com/f/cases/19417 http://files.pharo.org/image/60/60317.zip

Dec. 5, 2016