On 17 December 2012 21:41, Herby VojÄÃk <herby@mailbox.sk> wrote:
Eliot Miranda wrote:
On Mon, Dec 17, 2012 at 10:41 AM, Andrew P. Black <black@cs.pdx.edu <mailto:black@cs.pdx.edu>> wrote:
Two things make a class abstract.
One is that it has methods that a subclass /must/ override â that is
captured by #hasAbstractMethods.
The other is that the class cannot be instantiated â normally because it has overridden new. It can be the case that an abstract class defines only CONCRETE methods for its subclasses, but still is abstract. So, it seems to me that #isAbstractClass is not subsumed by #hasAbstractMethods.
A trait "AbstactClassT" could define #new to be "self error: 'Class ' , self name , ' is abstract and cannot be instantiated'" and #isAbstractClass to be ^ true.
+3.
Is it really such a good idea? Unless I have missed something, the poor subclass will have lot of trouble with `super new`, not to mention the need to override #isAbstractClass.
+1
For this to work, Behavior >> new would need to be overridden to throw this error is `self isAbstractClass` is true. And isAbstractClass itself, to leave the burden off of subclasses, would probably need to be generated as `isAbstractClass ^ Foo == self` so trait could not help here (unless I am able to find out the method definition class by some `thisContext method homeClass`-like magic.
The magic is: self class == thisContext method methodClass .. and yes. i don't like that. Which just underlines my previous comment, that "abstract" concept in smalltalk applicable only on per-method basis.. but not per-class (like in other languages). -- Best regards, Igor Stasenko.