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)