- Pharo-dev - lists.pharo.org

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

Re: [Pharo-dev] how implement isAbstract?

by Max Leske

On 30 Mar 2019, at 20:56, Denis Kudriashov wrote: > Hi Max. > > ÑÐ±, 30 Ð¼Ð°Ñ. 2019 Ð³. Ð² 19:08, Max Leske <maxleske(a)gmail.com>: > >> Hi Denis, >> >> I'm not too happy with any of those. For my own applications I use the >> following: >> >> isAbstract >> ^ self subclasses notEmpty and: [ >> (self class localSelectors includes: #isReallyAbstract) not or: [ >> self isReallyAbstract ] ] >> >> isReallyAbstract >> "Override this method in any class that has children but should >> *not* be considered abstract (while the children may be)." >> ^ true >> >> The reason, as stated in the method comment, is that in nearly all of my >> cases a class with subclasses should be considered abstract. Now, I don't >> want to go and implement #isAbstract on each of those classes but at the >> same time I need an escape hatch *which is not inherited*. >> That's why I work around method lookup by checking for the existence of >> the method first. >> >> I don't like how I have to hack around the method lookup but this works >> far better from me than the class equality / identity check. >> >> On 30 Mar 2019, at 19:35, Denis Kudriashov wrote: >> >> 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 >> >> Otherwise, this would be my preferred method: >> 1. minimum number of byte codes >> > Why it is important? > If it is about speed then I don't believe you :) because your approach is > very far from being optimized and I guess you are ok with that. I know, and you're right of course. It's just the way I feel about the code :) > >> 2. Simple for refactoring tools to update the binding >> 3. no use of #name >> >> Cheers, >> Max >> >> 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

Future 32-bit support

by Ben Coman

Regarding "PharoLaunched Windows 32bits Pharo 8 image raises primitive failed error" because there seems to be no Pharo 8 32-bit Windows VM configured for PharoLauncher https://github.com/pharo-project/pharo/issues/3053 and considering... * Mojave is Apple's last version of macOS to support 32-bit apps https://appleinsider.com/articles/18/06/05/mojave-is-apples-last-version-of… what is benefit of supporting 32-bit on those platforms? Perhaps 32-bit VMs are just useful for smaller Linux IoT platforms? cheers -ben

March 31, 2019