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