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 <[email protected]> wrote: > > On 1 Apr 2019, at 09:54, Henrik Sperre Johansen > <[email protected]> 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) >
