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 <[email protected]> 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 <[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) >> > -- www.feenk.com "If you interrupt the barber while he is cutting your hair, you will end up with a messy haircut."
