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