Why not just add an instance variable in Class if the feature is that important ? Of course, then it's better to add class creation messages to initialize the variable... (and adapt various tools) Nicolas 2012/12/17 Herby VojÄÃk <herby@mailbox.sk>:
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.
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.
Andrew -- best, Eliot
Herby