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 <[email protected]> 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 <[email protected]> wrote: >> >> >> >>> Am 30.03.2019 um 21:05 schrieb Denis Kudriashov <[email protected]>: >>> >>> 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 <[email protected]>: >>>> 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 >>>> >
