[squeak-dev] Re: Class>>binding broken

Nicolas Cellier nicolas.cellier.aka.nice at gmail.com
Wed Feb 3 08:36:30 UTC 2010


2010/2/3 Andreas Raab <andreas.raab at gmx.de>:
> Nicolas Cellier wrote:
>>
>> 2010/2/3 Igor Stasenko <siguctua at gmail.com>:
>>>
>>> - a compiled method's methodClass should always point to a class
>>> object, which owns a method dict where that method installed to. There
>>> should be no excuses in what shape a class object currently are (like
>>> transition from old class shape to a new one),
>>> because assignment of wrong methodClass could lead to fatal error(s) in
>>> VM.
>>>
>>> So, i assume that current implementation is incorrect, because it
>>> installs a method and violates that rule.
>>> Please, no deferring, because it causing more problems (leads to more
>>> complex code as well as putting extra responsibility on tools, which
>>> loading the code to take care of this issue).
>>>
>>
>> Doesn't this raise the problem of super semantic in a trait ?
>
> No. The meaning of "super" is uniquely defined by the class a trait is used
> in.  For any method in class Foo "super" means (Foo superclass) regardless
> of whether the method originates from a trait or not. For a trait itself
> "super" is meaningless, since traits have no "superclass" in the classic
> sense.
>
> Cheers,
>  - andreas
>

Oh, I realize i misunderstood... I thought the methodClass was
pointing to Trait when Igor wrote the exact contrary.
Case of slow neuron warming up ;)

Nicolas



More information about the Squeak-dev mailing list