- Pharo-dev - lists.pharo.org

Re: [Pharo-dev] Generate accessors refactoring

by Denis Kudriashov

2016-12-08 14:18 GMT+01:00 Denis Kudriashov <dionisiydk(a)gmail.com>: > To be clear, you don't mean Do Nothing; you mean Issue an Error and Abort >> the Refactoring right? > > > No. "Do Nothing" means that if we already have method with instVar name we > will skip this accessor. So we will not generate setter if there is already > method #instVar:. No matter if this method do something wrong inside. But getter will be generated in that case. No abort.

Dec. 8, 2016

Re: [Pharo-dev] Generate accessors refactoring

by Denis Kudriashov

Hi Eliot 2016-12-08 14:11 GMT+01:00 Eliot Miranda <eliot.miranda(a)gmail.com>: > To be clear, you don't mean Do Nothing; you mean Issue an Error and Abort > the Refactoring right? No. "Do Nothing" means that if we already have method with instVar name we will skip this accessor. So we will not generate setter if there is already method #instVar:. No matter if this method do something wrong inside.

Dec. 8, 2016

Re: [Pharo-dev] Drastically improving the messageNotUnderstood title

by Eliot Miranda

> On Dec 8, 2016, at 3:14 AM, Dimitris Chloupis <kilon.alios(a)gmail.com> wrote: > > I think > > Message does not exist > > Makes more sense, I always found the use of the word understood kinda weird But messages that do exist can be not understood. For example Array new add: 1. The exists wording is wrong and misleading. >> On Thu, 8 Dec 2016 at 10:38, phil(a)highoctane.be <phil(a)highoctane.be> wrote: >> MyClass did not understand #message >> >> Phil >> >> >> On Thu, Dec 8, 2016 at 11:24 AM, Denis Kudriashov <dionisiydk(a)gmail.com> wrote: >> >> 2016-12-08 10:59 GMT+01:00 phil(a)highoctane.be <phil(a)highoctane.be>: >> What if the method is on class side? >> >> Good question. It will be >> an instance of MyClass class did not understand #message >> which of course not so good. What you suggest? >>

Dec. 8, 2016

Re: [Pharo-dev] Generate accessors refactoring

by Aliaksei Syrel

Could we deselect check box by default in Nautilus if refactoring suggests instVar1 / instVar1? Every time have to go through the list and deselect... Cheers, Alex On 8 December 2016 at 14:11, Eliot Miranda <eliot.miranda(a)gmail.com> wrote: > Hi Nicolas, > > On Dec 8, 2016, at 1:16 AM, Nicolas Passerini <npasserini(a)gmail.com> > wrote: > > Let me recapitulate a little. > A) What to do in case that a method with same selector already exists in > the same class? > So far I think we've come up with four ideas: > 1. Create with an alternative name such as instVar1 / instVar1: > 2. Create with an alternative name but ask the user what the name should > be. > 3. Replace existing method with simple accessor. > 4. Do nothing. > > > To be clear, you don't mean Do Nothing; you mean Issue an Error and Abort > the Refactoring right? > > > I think that the last one is the best alternative and should be the > default action. Let me analyze the others: > 1. Is the current behavior, but I always end up deleting the method, I > can't think of a situation in which I want to keep a method named #name1 . > I know that there was a lot of thinking on top of this ideas, but even so > I think that we can (should) rethink things once in a while. > > 2. A little better, because lets me select a name better than #name1. > Still I do not like it, because this means that I have a Class with > - an instance variable 'name' > - a method #name which is not the accessor for 'name' inst var. > - and an accessor which is named in another way > > I think this can happen in two situations: > - The original #name method is in fact a (smarter) accessor (i.e., for > example it provides a lazy initialization). In this case the best action is > 4 => do nothing, accessor already exists, do not provide a new one. > - The original #name does something else, that maybe has nothing to do > with the variable name... in this case, I think the best is aborting the > refactor. I am not proposing that refactoring browser should abort the > refactor automatically, probably not, but that is what I would do as user: > my class has a weird name clash, so I should rename either the inst var or > the method, it has no automatic solution. > > I am not sure about how the "generate accessors" could help me coping with > name clashes, but I do not like generating accessor with another name > different from the inst var name is a good idea. We could have this as an > option to the user, but should not be the default. > > 3. This is really dangerous, we shouldn't do it. I am not sure if someone > would like to have this as a (non default) option. > > > B) What if the colliding method is in a superclass? > Well, pretty much the same but: > - in option 3 instead of replacing a method you could override it. > - the method in the superclass could not be a "smarter accessor" unless > you are trying to create accessors in subclass for an inst var in the > superclass... I do not like it. So I'd consider it allways as a name clash. > > Then I think that the best option is still do nothing (option 4). You > could offer to create method with another name as alternative (option 2)... > but I still think that this kind of name "coincidences" may introduce bugs > in the future and should be avoided. > > C) Colliding methods in subclasses. > Here we have a more subtle situation because the existing method could be > a smarter accessor, that even could have its motivation to be there (for > example because initialization code only is useful for one subclass). > > I still think that doing nothing could be a safe solution, better than > creating it with an alternative name (but we could allow it also). > > Here we could think also about writing the accessor, because it will not > override preexistent behavior. But we have to think about a few situations: > - Easy, if any of the colliding methods (they could be serveral one for > each subclass) is not a smarter accessor... we have name clashes and we > cannot do anything. > - If all colliding methods are smart accessors, we could create one in the > superclass, provided that there exists at least one subclass which does not > provide its own implementation. > > > Of course there is not precise way of determining if a preexistent method > can be considered as a smarter accessor or not... so we only can let the > user decide. > > To resume: > - Doing nothing will be the best default as it is suitable for all cases, > and can not do any harm. > - Creating methods with alternative names could be optional, but shouldn't > be default. In this case I prefer to ask the user for a name instead of > creating one automatically. > - Creating the method even in case of collision can be dangerous... I am > not sure if we should even allow it as an option. > > 2016-12-07 0:03 GMT+01:00 Ben Coman <btc(a)openinworld.com>: > >> How about mostly keeping the existing behaviour, but default to >> collisions being deselected? >> Then at least you don't need to search for it. >> It minimises the chance of missing it by mistake. >> The deselected item easily stands out to be reselected if required. >> >> P.S. An additional side idea: If collision is from a superclass then >> append (Superclass>>name) to the list item, and clicking on it shows a >> code dialog to the right similar to Spotter code review pane, to make >> a review easier. >> >> cheers -ben >> >> On Tue, Dec 6, 2016 at 10:09 PM, Yuriy Tymchuk <yuriy.tymchuk(a)me.com> >> wrote: >> > 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>: >> >> >> >> >> >> 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. 8, 2016

Re: [Pharo-dev] Generate accessors refactoring

by Eliot Miranda

Hi Nicolas, > On Dec 8, 2016, at 1:16 AM, Nicolas Passerini <npasserini(a)gmail.com> wrote: > > Let me recapitulate a little. > A) What to do in case that a method with same selector already exists in the same class? > So far I think we've come up with four ideas: > 1. Create with an alternative name such as instVar1 / instVar1: > 2. Create with an alternative name but ask the user what the name should be. > 3. Replace existing method with simple accessor. > 4. Do nothing. To be clear, you don't mean Do Nothing; you mean Issue an Error and Abort the Refactoring right? > > I think that the last one is the best alternative and should be the default action. Let me analyze the others: > 1. Is the current behavior, but I always end up deleting the method, I can't think of a situation in which I want to keep a method named #name1 . > I know that there was a lot of thinking on top of this ideas, but even so I think that we can (should) rethink things once in a while. > > 2. A little better, because lets me select a name better than #name1. Still I do not like it, because this means that I have a Class with > - an instance variable 'name' > - a method #name which is not the accessor for 'name' inst var. > - and an accessor which is named in another way > > I think this can happen in two situations: > - The original #name method is in fact a (smarter) accessor (i.e., for example it provides a lazy initialization). In this case the best action is 4 => do nothing, accessor already exists, do not provide a new one. > - The original #name does something else, that maybe has nothing to do with the variable name... in this case, I think the best is aborting the refactor. I am not proposing that refactoring browser should abort the refactor automatically, probably not, but that is what I would do as user: my class has a weird name clash, so I should rename either the inst var or the method, it has no automatic solution. > > I am not sure about how the "generate accessors" could help me coping with name clashes, but I do not like generating accessor with another name different from the inst var name is a good idea. We could have this as an option to the user, but should not be the default. > > 3. This is really dangerous, we shouldn't do it. I am not sure if someone would like to have this as a (non default) option. > > > B) What if the colliding method is in a superclass? > Well, pretty much the same but: > - in option 3 instead of replacing a method you could override it. > - the method in the superclass could not be a "smarter accessor" unless you are trying to create accessors in subclass for an inst var in the superclass... I do not like it. So I'd consider it allways as a name clash. > > Then I think that the best option is still do nothing (option 4). You could offer to create method with another name as alternative (option 2)... but I still think that this kind of name "coincidences" may introduce bugs in the future and should be avoided. > > C) Colliding methods in subclasses. > Here we have a more subtle situation because the existing method could be a smarter accessor, that even could have its motivation to be there (for example because initialization code only is useful for one subclass). > > I still think that doing nothing could be a safe solution, better than creating it with an alternative name (but we could allow it also). > > Here we could think also about writing the accessor, because it will not override preexistent behavior. But we have to think about a few situations: > - Easy, if any of the colliding methods (they could be serveral one for each subclass) is not a smarter accessor... we have name clashes and we cannot do anything. > - If all colliding methods are smart accessors, we could create one in the superclass, provided that there exists at least one subclass which does not provide its own implementation. > > > Of course there is not precise way of determining if a preexistent method can be considered as a smarter accessor or not... so we only can let the user decide. > > To resume: > - Doing nothing will be the best default as it is suitable for all cases, and can not do any harm. > - Creating methods with alternative names could be optional, but shouldn't be default. In this case I prefer to ask the user for a name instead of creating one automatically. > - Creating the method even in case of collision can be dangerous... I am not sure if we should even allow it as an option. > > 2016-12-07 0:03 GMT+01:00 Ben Coman <btc(a)openinworld.com>: >> How about mostly keeping the existing behaviour, but default to >> collisions being deselected? >> Then at least you don't need to search for it. >> It minimises the chance of missing it by mistake. >> The deselected item easily stands out to be reselected if required. >> >> P.S. An additional side idea: If collision is from a superclass then >> append (Superclass>>name) to the list item, and clicking on it shows a >> code dialog to the right similar to Spotter code review pane, to make >> a review easier. >> >> cheers -ben >> >> On Tue, Dec 6, 2016 at 10:09 PM, Yuriy Tymchuk <yuriy.tymchuk(a)me.com> wrote: >> > 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>: >> >> >> >> >> >> 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. 8, 2016

Re: [Pharo-dev] Drastically improving the messageNotUnderstood title

by Nicolas Cellier

2016-12-08 13:29 GMT+01:00 Denis Kudriashov <dionisiydk(a)gmail.com>: > > 2016-12-08 12:14 GMT+01:00 Dimitris Chloupis <kilon.alios(a)gmail.com>: > >> I think >> >> Message does not exist >> > > It is not correct because in fact message exits and it is here in argument > of #doesNotUnderstood: and it is shown in degugger. > Executing a method (CompiledMethod) is how an object would react when receiving a message. Who is sending the message has (should have) no idea of which method exactly will be executed, or it least shouldn't have to care about it. It's encapsulated/delegated/private/you name it, IOW it's the responsibility of the object we sent the message to. So in Smalltalk we have to think in term of message, not method. DNU happens when the method lookup failed. I fail to see what is not crystal clear?

Dec. 8, 2016

Re: [Pharo-dev] Drastically improving the messageNotUnderstood title

by phil＠highoctane.be

Kilon, Check the MessageSend class and its users. There are a lot of interesting things one can do there. Phil On Thu, Dec 8, 2016 at 1:29 PM, Denis Kudriashov <dionisiydk(a)gmail.com> wrote: > > 2016-12-08 12:14 GMT+01:00 Dimitris Chloupis <kilon.alios(a)gmail.com>: > >> I think >> >> Message does not exist >> > > It is not correct because in fact message exits and it is here in argument > of #doesNotUnderstood: and it is shown in degugger. >

Dec. 8, 2016

Re: [Pharo-dev] Drastically improving the messageNotUnderstood title

by Denis Kudriashov

2016-12-08 12:14 GMT+01:00 Dimitris Chloupis <kilon.alios(a)gmail.com>: > I think > > Message does not exist > It is not correct because in fact message exits and it is here in argument of #doesNotUnderstood: and it is shown in degugger.

Dec. 8, 2016

Re: [Pharo-dev] Drastically improving the messageNotUnderstood title

by phil＠highoctane.be

This is because you have been shaped by those other languages. Message is not Operation which is not Method. There are lots of mechnisms that are based on hooking in the #DNU mechanism. That's a key feature of Pharo, so, trying to hide that fact is not helping. #DNU is "cannot make sense of what you are asking me to do, Dave". <Subject> <Verb> Phil Phil Phil On Thu, Dec 8, 2016 at 12:34 PM, Dimitris Chloupis <kilon.alios(a)gmail.com> wrote: > First of all you will never see the word message mentioned in those > languages you mentioned > Second the word , understood, says nothing about the nature of the problem > to a beginner > > Is it that the method does not exist ? > Or is it that method exists but message does not ? > Or is it that the method does something it should not ? > Or is the VM that has problem executing the method ? > > > > On Thu, 8 Dec 2016 at 11:27, Aliaksei Syrel <alex.syrel(a)gmail.com> wrote: > >> "Message(method) does not exist" happens in C/Java/etc when we *call* a >> method. >> "Message not understood by an object" happens in Smalltalk/Ruby when we >> *send* a message. >> >> I like this conceptual distinguishment between calling a method and >> sending a message. >> >> Cheers, >> Alex >> >

Dec. 8, 2016

Re: [Pharo-dev] :: Separator in class names

by phil＠highoctane.be

I like that :: idea for structuring the global space. What I would refrain from is to into the Java style packages/classloaders/Jigsaw/OSGi thing. So, that is not what you are after, so that is good. Having a smaller number of well working libraries that we refine feels superior to a myriad of ad hoc things put together. I'd rather have more advanced access mechanisms (and let go of any compatibility with other Smalltalks) in order to have a poweful environment to develop in. We do have a system, so, the focus should be on mechanisms and on the "Pharo way to solve problems" than on compatibility. For example, I'd better have a way to write code using other syntaxes and getting compiled into Pharo code and then in bytecode in order to express higher order things. Compatibility is only going to glue us to the blue plane. Phil On Thu, Dec 8, 2016 at 12:30 PM, Torsten Bergmann <astares(a)gmx.de> wrote: > Dale wrote: > >Because of the obvious portability problems this would introduce, I > >would think that an attempt should be made to come up with a common > >namespace solution ... > > I'm not sure about the current namespace solutions existing today in > vendor driven Smalltalks. You and me were participants in the first > CampSmalltalk in San Diego in 2000 with many others trying to get the > Smalltalk's closer which was already hard at that time > because of the many dialects and differences (VW, VAST, Gemstone, Squeak, > ST/MT, Dolphin, ...) > > Some of this work influenced todays Smalltalk world with frameworks and > tools. Today Smalltalks shares not only basic core classes > but also a common unit framework and similar test runners, have code > exchange and formats, even a framework like Seaside could > somehow be managed "portable". > > But there was not much success in REALLY aligning all the proprietary > solutions regarding class libraries, common behavior of methods, > tools, UI or even frameworks. You cant file out, file in and just run. > > Because we have different pragma solutions, different foreign function > interfaces, different way of building tools ... even > differences on compiler and meta level. So "portability problems" are > already a reality for many other reasons. > > Dont get me wrong. I'm all ears if you see a way to build a "common" or > "portable" route for unified namespace solution, but to make > this a reality: > > - commercial vendors would have to see a need for (another) portable > solution > - would need to invest into this topic with time and resources > - would have to jump onto the "open" and MIT licensed bandwagon to share > with open source Smalltalks like Squeak and Pharo > - would have to adopt their own solutions to a new portable one > - you would need to get all the different interests under one umbrella > > Which I doubt such a thing will happen because vendors already have own > proprietary existing namespace solutions. Even when this would > be possible they would have to invest in explaining this to their > customers who also would need to migrate from existing vendor > namespace solutions. > > This thread is not about Namespaces, just about an optional separator in > global names. So independent from the reasons to start this thread > I doubt we will ever find a path to a unified namespace solution. You can > call me a pessimist in this regard, even in having a short-term > common namespace solution for Pharo, Squeak and Cuis. > > >something that a small community cannot really afford to do > > Community is not big ... but growing. At least from what I see in open > source Smalltalks like Squeak, Pharo, Cuis, ... with new > community members, ideas, frameworks, books, unifying VM, ... > > We would continue to be a small community if our world would have stopped > and kept the things the way they were defined initially in ST. > I would not like to imagine the size of the overall ST community without > the fresh air of these open source Smalltalks. > > Maybe I'm mistaken but so far Pharo is already the one who EXPLORES new > routes with Traits, Slots, MetaLinks, OpalCompiler, ... > often these are already "non-portable". So while you can use them if you > are in need of them you should stay away from them > if you have portability to other Smalltalks in mind. Right? > > This does not solve the portability issue but provides freedem: because > you can share with other Smalltalks if necessary - but also > allows you to follow new paths, use slots and other. > > But back to the topic: > ====================== > Please do not misunderstood my orginal post: I DONT want to have or > discuss a new and perfect namespace solution now as an outcome > here. Usually when similar threads were discussed we only agreed that this > never gets reality. ;) > > I JUST want to change the single method #isValidGlobalName to be MORE > FLEXIBLE and to allow for an EXPLICIT and OPTIONAL > SEPARATOR IN GLOBAL NAMES. Nothing less but also nothing more. So this is > about an optional separator in global names, not > about a full namespace solution. > > By allowing such a separator anyone (including me) who feels the need to > experiment or try out new paths can then > play with it: > > - maybe just for readability to write prefixed classes like this > "KillerApp::Window" > - maybe just to avoid conflicts as with a better separated prefix > ("MyKillApp::Person" vs. "YouKillerApp::Person") > - maybe to experiment with having two versions of a class inside of the > image "OldVersion::MyClass" and "NewVersion::MyClass" > - maybe because you want to import/map namespace from other languages > like Java/.NET/C++/... to it > (like mapping Java to Pharo as org::apache::commons::lang::StringUtils > and so on) to experiment with Pharo as a > multilanguage engine or experiment in a better JNIPort > - maybe because you want to map different platform facilities or > libraries ("Common::Window", "Windows::Window", > "OSX::Window", "GTK::Window", ...) > - maybe to provide useful shadow classes that are not visible by default > in regular tools ("Shadows::Object", "Shadows::Boolean", ...) > - maybe to be able to import and separate classes from different > Smalltalk systems ("VW::Object", "VAST::Object", ...) > - and yes: maybe also to do initial experiments towards a future portable > or non-portable namespace solution > - ... > - [ADD YOUR OWN IDEAS HERE] > > > So anything I want is a single and small step forward: the possibility in > Pharo 6 for global names to allow a > COMPLETELY OPTIONAL separator without having to "dirty patch" the method > #isValidGlobalName in the base image. > > So if one wants to write regular code or even portable code and code that > is traditional, working with all tools > he could and should stay away from this OPTIONAL separator possibility. > Nothing changes on the usual Pharo and Smalltalk side, > you can code and share as before. > > But if one feels the need to use such a possibility for own custom stuff > or experiments it is there and one can use it. > I feel a very strong need on my side for such experiments because I would > like to explore new grounds with it. I can > patch/overwrite the method in my custom images - but this is not so clean > and nice. Pharo should give this freedom out > of the box and I hope that you agree with me. > > Maybe others have similar ideas and want to experiment as well. Thats why > I opened this thread - if the community > supports the idea and shares similar visions I will open a bug, provide a > slice and we include it. In my opinion it > opens new opportunities. > > If community disagrees and it will not become part of the base image out > of the box (or only as part of a full namespace solution) > I will continue patching my custom images. I'm fine with that as well - > but then at least I tried to get this in. > > Thanks > T. > > > > > > >

Dec. 8, 2016