- Pharo-dev - lists.pharo.org

Re: [Pharo-dev] how implement isAbstract?

by Tim Mackinnon

On 1 Apr 2019, at 09:54, Henrik Sperre Johansen <henrik.s.johansen(a)veloxit.no> wrote: > > Or, if the class has subclasses, one could get a suggestion/action to > implement the missing method as > missingMethod > ^self subclassResponsibility > > Which also has the benefit of working nicely with the "expected (or was that > "missing"?) protocol" functionality. > Unless you meant something else? I donât know if we are all talking about the same thing. In my image, I have a class where I havenât got the isAbstract defined, and so Calypso shows a red message - as it thinks Iâm supposed to implement #execute (if it knows my intent that my class is abstract, then it doesnât show the red warning). I think this is Denisâ question? Sure, if I choose to use the abstract class, then its my choice, but as a lint checker -having useful warnings is helpful. But it is a nuisance defining isAbstract - and Iâd almost prefer it assumes its abstract in this case (the normal expectations?) unless I tag it as concrete and signal to users that they might consider using my class (its probably a design smell these days though)

April 1, 2019

Re: [Pharo-dev] how implement isAbstract?

by Henrik Sperre Johansen

I guess I could have added additional constraints "and the missing method is called from a method on the "abstract class", and the missing method is defined on subclasses", but I thought that implicit from the context :) To me, an abstract class is one you either can't instatiate (through overriding new), or one containing methods which delegate to methods implemented by subclasses, so it makes no sense to use instances of the class itself. The use case is addressed at the method level, yes, but it *is* for the typical meaning associated with a class being abstract, at least to me. Cheers, Henry Tudor Girba-2 wrote > This is a use case that is addressed at the level of the method, not of a > class. > > I see the issue similarly to Stef: as I can utilize a class, it has little > meaning to call it abstract. A missing method has a different meaning from > the typical meaning associated with a class being abstract. > > Cheers, > Doru > > >> On Apr 1, 2019, at 10:54 AM, Henrik Sperre Johansen < > henrik.s.johansen@ > > wrote: >> >> Tim Mackinnon wrote >>> Calypso warns you about missing methods if it doesnât understand a class >>> is abstract, so itâs useful to avoid those warnings otherwise you become >>> desensitised to them. >>> >>> Tim >> >> Or, if the class has subclasses, one could get a suggestion/action to >> implement the missing method as >> missingMethod >> ^self subclassResponsibility >> >> Which also has the benefit of working nicely with the "expected (or was >> that >> "missing"?) protocol" functionality. >> Unless you meant something else? >> >> Cheers, >> Henry >> >> >> >> -- >> Sent from: http://forum.world.st/Pharo-Smalltalk-Developers-f1294837.html >> > > -- > www.feenk.com > > "Problem solving should be focused on describing > the problem in a way that makes the solution obvious." -- Sent from: http://forum.world.st/Pharo-Smalltalk-Developers-f1294837.html

April 1, 2019

Re: [Pharo-dev] how implement isAbstract?

by Tudor Girba

This is a use case that is addressed at the level of the method, not of a class. I see the issue similarly to Stef: as I can utilize a class, it has little meaning to call it abstract. A missing method has a different meaning from the typical meaning associated with a class being abstract. Cheers, Doru > On Apr 1, 2019, at 10:54 AM, Henrik Sperre Johansen <henrik.s.johansen(a)veloxit.no> wrote: > > Tim Mackinnon wrote >> Calypso warns you about missing methods if it doesnât understand a class >> is abstract, so itâs useful to avoid those warnings otherwise you become >> desensitised to them. >> >> Tim > > Or, if the class has subclasses, one could get a suggestion/action to > implement the missing method as > missingMethod > ^self subclassResponsibility > > Which also has the benefit of working nicely with the "expected (or was that > "missing"?) protocol" functionality. > Unless you meant something else? > > Cheers, > Henry > > > > -- > Sent from: http://forum.world.st/Pharo-Smalltalk-Developers-f1294837.html > -- www.feenk.com "Problem solving should be focused on describing the problem in a way that makes the solution obvious."

April 1, 2019

[Pharo 8.0] Build #206: Revert "Integrating UndefinedClass, ClassDefinition and modified classBuilderâ¦"

by ci-pharo-ci-jenkins2＠inria.fr

There is a new Pharo build available! The status of the build #206 was: SUCCESS. The Pull Request #3117 was integrated: "Revert "Integrating UndefinedClass, ClassDefinition and modified classBuilderâ¦"" Pull request url: https://github.com/pharo-project/pharo/pull/3117 Issue Url: https://github.com/pharo-project/pharo/issues/revert Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

April 1, 2019

Re: [Pharo-dev] how implement isAbstract?

by Henrik Sperre Johansen

Tim Mackinnon wrote > Calypso warns you about missing methods if it doesnât understand a class > is abstract, so itâs useful to avoid those warnings otherwise you become > desensitised to them. > > Tim Or, if the class has subclasses, one could get a suggestion/action to implement the missing method as missingMethod ^self subclassResponsibility Which also has the benefit of working nicely with the "expected (or was that "missing"?) protocol" functionality. Unless you meant something else? Cheers, Henry -- Sent from: http://forum.world.st/Pharo-Smalltalk-Developers-f1294837.html

April 1, 2019

Re: [Pharo-dev] how implement isAbstract?

by Tim Mackinnon

Calypso warns you about missing methods if it doesnât understand a class is abstract, so itâs useful to avoid those warnings otherwise you become desensitised to them. Tim Sent from my iPhone > On 31 Mar 2019, at 22:06, ducasse <stepharo(a)netcourrier.com> wrote: > > Frankly I found strange that we care about this because > we can still instantiate an abstract class > and I do not really see how annotating that a class is abstract help us. > If I can instantiate an object and send messages and the class is abstract but there is no > usage of abstract messages who cares? > May be I do not have such scenarios. > > Stef > >> On 31 Mar 2019, at 22:30, Norbert Hartl <norbert(a)hartl.name> wrote: >> >> >> >>> Am 30.03.2019 um 21:05 schrieb Denis Kudriashov <dionisiydk(a)gmail.com>: >>> >>> We can also look into it from the other side. All these methods are definitely a kind of code duplication. >>> I think what we need here is an explicit property for classes. It could be even part of class definition. >> >> I use it myself but it always feels a bit strange. On the one hand a class is abstract if it includes something like subclassResponsibility and on the other hand we try to make it some kind of type. If it would be the latter one you could make that a Trait. Feels even more strange but .... >> >> Norbert >>> BTW do we plan new class definition in Pharo 8? >>> >>> ÑÐ±, 30 Ð¼Ð°Ñ. 2019 Ð³. Ð² 18:35, Denis Kudriashov <dionisiydk(a)gmail.com>: >>>> Hello. >>>> >>>> We did recently several cleanups by marking abstract classes as abstract using #isAbstract method (https://github.com/pharo-project/pharo/pull/3087, https://github.com/pharo-ide/Calypso/pull/462) . >>>> >>>> I would like to discuss here and decide what the right way to implement this method. >>>> >>>> The logic behind is to only return true when receiver is defining class of this method. And it should be false for any subclasses (if they do not implement own #isAbstract method). >>>> >>>> There is old pattern for implementation to compare name of class: >>>> >>>> MyAbstractClass class>>isAbstract >>>> ^self name == #MyAbstractClass >>>> >>>> It is used in many places (mostly tests). And it was used in recent Pharo PR (3087). >>>> >>>> We have another pattern in other places which simply compare self with class: >>>> >>>> MyAbstractClass class>>isAbstract >>>> ^self == MyAbstractClass >>>> >>>> And in Calypso I used "more simplified" version using equality: >>>> >>>> MyAbstractClass class>>isAbstract >>>> ^self = MyAbstractClass >>>> >>>> I think we would all agree that simplest version is last one. It does not raise any question about why we compare name or why we use identity comparison. So this is my choice in this discussion. >>>> >>>> Please write arguments about your preferred implementation. And let's choose single way at the end. There is an idea to add a command into browser to make classes abstract. And this decision will be used as a template. >>>> >>>> Best regards, >>>> Denis >>>> >

March 31, 2019

Re: [Pharo-dev] how implement isAbstract?

by ducasse

Frankly I found strange that we care about this because we can still instantiate an abstract class and I do not really see how annotating that a class is abstract help us. If I can instantiate an object and send messages and the class is abstract but there is no usage of abstract messages who cares? May be I do not have such scenarios. Stef > On 31 Mar 2019, at 22:30, Norbert Hartl <norbert(a)hartl.name> wrote: > > > > Am 30.03.2019 um 21:05 schrieb Denis Kudriashov <dionisiydk(a)gmail.com <mailto:dionisiydk@gmail.com>>: > >> We can also look into it from the other side. All these methods are definitely a kind of code duplication. >> I think what we need here is an explicit property for classes. It could be even part of class definition. > > I use it myself but it always feels a bit strange. On the one hand a class is abstract if it includes something like subclassResponsibility and on the other hand we try to make it some kind of type. If it would be the latter one you could make that a Trait. Feels even more strange but .... > > Norbert >> BTW do we plan new class definition in Pharo 8? >> >> ÑÐ±, 30 Ð¼Ð°Ñ. 2019 Ð³. Ð² 18:35, Denis Kudriashov <dionisiydk(a)gmail.com <mailto:dionisiydk@gmail.com>>: >> Hello. >> >> We did recently several cleanups by marking abstract classes as abstract using #isAbstract method (https://github.com/pharo-project/pharo/pull/3087 <https://github.com/pharo-project/pharo/pull/3087>, https://github.com/pharo-ide/Calypso/pull/462 <https://github.com/pharo-ide/Calypso/pull/462>) . >> >> I would like to discuss here and decide what the right way to implement this method. >> >> The logic behind is to only return true when receiver is defining class of this method. And it should be false for any subclasses (if they do not implement own #isAbstract method). >> >> There is old pattern for implementation to compare name of class: >> >> MyAbstractClass class>>isAbstract >> ^self name == #MyAbstractClass >> >> It is used in many places (mostly tests). And it was used in recent Pharo PR (3087). >> >> We have another pattern in other places which simply compare self with class: >> >> MyAbstractClass class>>isAbstract >> ^self == MyAbstractClass >> >> And in Calypso I used "more simplified" version using equality: >> >> MyAbstractClass class>>isAbstract >> ^self = MyAbstractClass >> >> I think we would all agree that simplest version is last one. It does not raise any question about why we compare name or why we use identity comparison. So this is my choice in this discussion. >> >> Please write arguments about your preferred implementation. And let's choose single way at the end. There is an idea to add a command into browser to make classes abstract. And this decision will be used as a template. >> >> Best regards, >> Denis >>

March 31, 2019

Re: [Pharo-dev] how implement isAbstract?

by Norbert Hartl

> Am 30.03.2019 um 21:05 schrieb Denis Kudriashov <dionisiydk(a)gmail.com>: > > We can also look into it from the other side. All these methods are definitely a kind of code duplication. > I think what we need here is an explicit property for classes. It could be even part of class definition. I use it myself but it always feels a bit strange. On the one hand a class is abstract if it includes something like subclassResponsibility and on the other hand we try to make it some kind of type. If it would be the latter one you could make that a Trait. Feels even more strange but .... Norbert > BTW do we plan new class definition in Pharo 8? > > ÑÐ±, 30 Ð¼Ð°Ñ. 2019 Ð³. Ð² 18:35, Denis Kudriashov <dionisiydk(a)gmail.com>: >> Hello. >> >> We did recently several cleanups by marking abstract classes as abstract using #isAbstract method (https://github.com/pharo-project/pharo/pull/3087, https://github.com/pharo-ide/Calypso/pull/462) . >> >> I would like to discuss here and decide what the right way to implement this method. >> >> The logic behind is to only return true when receiver is defining class of this method. And it should be false for any subclasses (if they do not implement own #isAbstract method). >> >> There is old pattern for implementation to compare name of class: >> >> MyAbstractClass class>>isAbstract >> ^self name == #MyAbstractClass >> >> It is used in many places (mostly tests). And it was used in recent Pharo PR (3087). >> >> We have another pattern in other places which simply compare self with class: >> >> MyAbstractClass class>>isAbstract >> ^self == MyAbstractClass >> >> And in Calypso I used "more simplified" version using equality: >> >> MyAbstractClass class>>isAbstract >> ^self = MyAbstractClass >> >> I think we would all agree that simplest version is last one. It does not raise any question about why we compare name or why we use identity comparison. So this is my choice in this discussion. >> >> Please write arguments about your preferred implementation. And let's choose single way at the end. There is an idea to add a command into browser to make classes abstract. And this decision will be used as a template. >> >> Best regards, >> Denis >>

March 31, 2019

Re: [Pharo-dev] how implement isAbstract?

by ducasse

> On 30 Mar 2019, at 21:05, Denis Kudriashov <dionisiydk(a)gmail.com> wrote: > > We can also look into it from the other side. All these methods are definitely a kind of code duplication. > I think what we need here is an explicit property for classes. It could be even part of class definition. > BTW do we plan new class definition in Pharo 8? so far not. Just a better infrastructure. I also think that this abstract point is not really exciting. Stef

March 31, 2019

Re: [Pharo-dev] how implement isAbstract?

by Max Leske

On 30 Mar 2019, at 21:05, Denis Kudriashov wrote: > We can also look into it from the other side. All these methods are > definitely a kind of code duplication. > I think what we need here is an explicit property for classes. It > could be > even part of class definition. I'm not sure whether that's the right thing to do but I definitely like where you're going. BTW, class initialization via Monticello (class side #initialize) also doesn't use inheritance (although I've always considered that a bug). I.e., Monticello only evalutes #initialize on the class that installed the #initialize method and not on any subclass. Maybe a general mechanism for marking a class as abstract could also include a mechanism to "override" method lookup. Just some thoughts. Max > BTW do we plan new class definition in Pharo 8? > > ÑÐ±, 30 Ð¼Ð°Ñ. 2019 Ð³. Ð² 18:35, Denis Kudriashov > <dionisiydk(a)gmail.com>: > >> Hello. >> >> We did recently several cleanups by marking abstract classes as >> abstract >> using #isAbstract method >> (https://github.com/pharo-project/pharo/pull/3087 >> , https://github.com/pharo-ide/Calypso/pull/462) . >> >> I would like to discuss here and decide what the right way to >> implement >> this method. >> >> The logic behind is to only return true when receiver is defining >> class of >> this method. And it should be false for any subclasses (if they do >> not >> implement own #isAbstract method). >> >> There is old pattern for implementation to compare name of class: >> >> MyAbstractClass class>>isAbstract >> ^self name == #MyAbstractClass >> >> >> It is used in many places (mostly tests). And it was used in recent >> Pharo >> PR (3087). >> >> We have another pattern in other places which simply compare self >> with >> class: >> >> MyAbstractClass class>>isAbstract >> ^self == MyAbstractClass >> >> >> And in Calypso I used "more simplified" version using equality: >> >> MyAbstractClass class>>isAbstract >> ^self = MyAbstractClass >> >> I think we would all agree that simplest version is last one. It does >> not >> raise any question about why we compare name or why we use identity >> comparison. So this is my choice in this discussion. >> >> Please write arguments about your preferred implementation. And let's >> choose single way at the end. There is an idea to add a command into >> browser to make classes abstract. And this decision will be used as a >> template. >> >> >> Best regards, >> Denis >> >>

March 31, 2019