I also find that the last one resonates with what I would expect - and a real class autocompletes easily too.
I also wonder if a class with subclasses should be considered abstract unless specifically marked otherwise (but we need a simple way of doing this if we can think of one - which isn’t overly clever) Tim Sent from my iPhone > On 30 Mar 2019, at 19:21, Cyril Ferlicot D. <[email protected]> wrote: > >> Le 30/03/2019 à 19:35, Denis Kudriashov a écrit : >> 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. >> >> > > Hi, > > Personally I always used the last one. (self = MyAbstractClass) > > At first it is because it's the first implementation I saw. Then later, > after seen the other two, I sticked with this one because it seems to be > the simpler for me and I like my code to stay the simpler possible if > there is no problem with that. > > Until now I never got a problem with this implementation. > >> Best regards, >> Denis >> > > > -- > Cyril Ferlicot > https://ferlicot.fr >
