Hi Andrei, Doru,

Sorry for the late reply, I've been away on vacations last week :).

Denis introduced originally the behaviour making classes return true for #isAbstract only when they had #subclassResponsibility methods in them.

Originally, if I'm not mistaken, it was to introduce the `should be implemented` protocol in Calypso: this was originally shown for subclasses of abstract classes that were not abstract themselves (under that definition).

My main point against that definition is that sometimes I have hierarchies like:

A <|- B <|- C

Where conceptually both A and B are abstract, but I only put the subclass responsibility methods in A.

However under that definition B was not considered as abstract, though in my design it was.

And then I had Calypso asking me all the time to <<implement>> the methods in the superclass, which I did not want to!

My point at the time (and that resulted in the split of isAbstract into hasAbstractMethods) was that (at least for me) the heuristic of having abstract methods was super weak.

A class is abstract by design and not necessarily because I can compute something from its implementation that tells me that maybe it is abstract.

I somehow mark a class as abstract because it is abstract, not the other way around.

On Tue, Apr 23, 2019 at 6:10 PM Tudor Girba <tudor@tudorgirba.com> wrote:

Hi,

I think that it is good that isAbstract does not mean isInstantiatable. However, I also think that isAbstract is too generic and that it would be better to have the tools implement their meaning rather than relying on a generic term.

Cheers,
Doru

> On Apr 23, 2019, at 5:58 PM, Andrei Chis <chisvasileandrei@gmail.com> wrote:
>
> I ended up being surprised today that classes that have abstract
> methods (send #subclassResponsibility) were returning false to
> `isAbstract` and true to `hasAbstractMethods`.
> I see that the behavior for isAbstract changed over the years: when it
> was added [1] it was checking for abstract methods. Then it was
> changed to always return false and allow overrides [2].
>
> Is there an explicit need to have/keep `isAbstract` at the class
> level? Users can still instantiate those classes, send message to them
> and get SubclassResponsibility errors. Tools could implement specific
> solutions for handling this.
>
> Cheers,
> Andrei
>
> [1] https://github.com/pharo-project/pharo/pull/541/files
> [2] https://github.com/pharo-project/pharo/pull/1090/files
>
> On Mon, Apr 1, 2019 at 3:02 PM Tim Mackinnon <tim@testit.works> wrote:
>>
>> On 1 Apr 2019, at 09:54, Henrik Sperre Johansen <henrik.s.johansen@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)
>>
>

--
www.feenk.com

"If you interrupt the barber while he is cutting your hair,
you will end up with a messy haircut."

��	Guille Polito Research Engineer Centre de Recherche en Informatique, Signal et Automatique de Lille CRIStAL - UMR 9189 French National Center for Scientific Research - http://www.cnrs.fr Web: http://guillep.github.io Phone: +33 06 52 70 66 13