[Pharo-project] about isAbstractClass
Hi guys I will deprecate isAbstractClass and introduce defineAbstractMethods. why? because as soon as we have an abstract method in Object nearly all the classes becomes abstract and this does not make sense. Now I can understand that we want to know if a class defineAbstractMethods and sometimes taking into account inheritance. http://code.google.com/p/pharo/issues/detail?id=7123 Stef
On 16 December 2012 16:34, Stéphane Ducasse <stephane.ducasse@inria.fr> wrote:
Hi guys
I will deprecate isAbstractClass and introduce defineAbstractMethods. why? because as soon as we have an abstract method in Object nearly all the classes becomes abstract and this does not make sense. Now I can understand that we want to know if a class defineAbstractMethods and sometimes taking into account inheritance. http://code.google.com/p/pharo/issues/detail?id=7123
well, since in smalltalk you can make everything extremely late bound, i wonder, if it makes any sense to apply such terminology to classes at all. these terms coming from static languages in their attempt to add OO..
Stef
-- Best regards, Igor Stasenko.
On Dec 16, 2012, at 7:29 PM, Igor Stasenko wrote:
On 16 December 2012 16:34, Stéphane Ducasse <stephane.ducasse@inria.fr> wrote:
Hi guys
I will deprecate isAbstractClass and introduce defineAbstractMethods. why? because as soon as we have an abstract method in Object nearly all the classes becomes abstract and this does not make sense. Now I can understand that we want to know if a class defineAbstractMethods and sometimes taking into account inheritance. http://code.google.com/p/pharo/issues/detail?id=7123
well, since in smalltalk you can make everything extremely late bound, i wonder, if it makes any sense to apply such terminology to classes at all. these terms coming from static languages in their attempt to add OO..
Because some people need that. Now defineAbstractMethods is much better than isAstractClass because it just describes a real situation. Does a class has any subclassResponsibility method. So this is a good compromise and encapsulation sendLiteralâ¦. in a nice little method is nice. stef
On Sun, Dec 16, 2012 at 10:34 PM, Stéphane Ducasse < stephane.ducasse@inria.fr> wrote:
On Dec 16, 2012, at 7:29 PM, Igor Stasenko wrote:
On 16 December 2012 16:34, Stéphane Ducasse <stephane.ducasse@inria.fr> wrote:
Hi guys
I will deprecate isAbstractClass and introduce defineAbstractMethods. why? because as soon as we have an abstract method in Object nearly all the classes becomes abstract and this does not make sense. Now I can understand that we want to know if a class defineAbstractMethods and sometimes taking into account inheritance. http://code.google.com/p/pharo/issues/detail?id=7123
well, since in smalltalk you can make everything extremely late bound, i wonder, if it makes any sense to apply such terminology to classes at all. these terms coming from static languages in their attempt to add OO..
Because some people need that. Now defineAbstractMethods is much better than isAstractClass because it just describes a real situation. Does a class has any subclassResponsibility method. So this is a good compromise and encapsulation sendLiteralâ¦. in a nice little method is nice.
what about hasAbstractMethods ? or at least definesAbstractMethods (do this class defines abstract methods?)
stef
-- Dr. Ciprian TEODOROV Ingénieur Développement CAO tél : 06 08 54 73 48 mail : ciprian.teodorov@gmail.com www.teodorov.ro
On 16/12/12 4:34 PM, Stéphane Ducasse wrote:
On Dec 16, 2012, at 7:29 PM, Igor Stasenko wrote:
On 16 December 2012 16:34, Stéphane Ducasse <stephane.ducasse@inria.fr> wrote:
Hi guys
I will deprecate isAbstractClass and introduce defineAbstractMethods. why? because as soon as we have an abstract method in Object nearly all the classes becomes abstract and this does not make sense. Now I can understand that we want to know if a class defineAbstractMethods and sometimes taking into account inheritance. http://code.google.com/p/pharo/issues/detail?id=7123
well, since in smalltalk you can make everything extremely late bound, i wonder, if it makes any sense to apply such terminology to classes at all. these terms coming from static languages in their attempt to add OO..
Because some people need that. Now defineAbstractMethods is much better than isAstractClass because it just describes a real situation. Does a class has any subclassResponsibility method. So this is a good compromise and encapsulation sendLiteralâ¦. in a nice little method is nice.
Better phrasing is: #definesAbstractMethods (note the define-'s'). The "defines" wording seems not quite right either. How about: #hasAbstractMethods #declaresAbstractMethods
On Sun, Dec 16, 2012 at 11:03 PM, Stéphane Ducasse <stephane.ducasse@inria.fr> wrote:
Good suggestion I will change it to hasAbstractMethods it looks much better. Tx for the suggestion.
what about 'additionalAbstractMethods' that would return the list of new abstract methods the class defines. -- Damien Cassou http://damiencassou.seasidehosting.st "Success is the ability to go from one failure to another without losing enthusiasm." Winston Churchill
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. Andrew
On Sun, Dec 16, 2012 at 11:03 PM, Stéphane Ducasse <stephane.ducasse@inria.fr> wrote:
Good suggestion I will change it to hasAbstractMethods it looks much better. Tx for the suggestion.
what about 'additionalAbstractMethods' that would return the list of new abstract methods the class defines.
On Mon, Dec 17, 2012 at 10:41 AM, Andrew P. Black <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.
Andrew
On Sun, Dec 16, 2012 at 11:03 PM, Stéphane Ducasse <stephane.ducasse@inria.fr> wrote:
Good suggestion I will change it to hasAbstractMethods it looks much better.
Tx for the suggestion.
what about 'additionalAbstractMethods' that would return the list of new abstract methods the class defines.
-- best, Eliot
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
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
On 17 December 2012 21:49, Nicolas Cellier <nicolas.cellier.aka.nice@gmail.com> wrote:
Why not just add an instance variable in Class if the feature is that important ?
yes, i'd like to know why it is important. Because for me this is not obvious. The only thing which comes to my mind is: to please Java guys? :)
Of course, then it's better to add class creation messages to initialize the variable... (and adapt various tools)
Nicolas
-- Best regards, Igor Stasenko.
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.
participants (9)
-
Andrew P. Black -
Ciprian Teodorov -
Damien Cassou -
Eliot Miranda -
Herby VojÄÃk -
Igor Stasenko -
Nicolas Cellier -
Stéphane Ducasse -
Yanni Chiu