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@hartl.name> wrote:

Am 30.03.2019 um 21:05 schrieb Denis Kudriashov <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@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