Yes, traits does not (re)defining the super send semantics.

On 3 February 2010 10:36, Nicolas Cellier
<nicolas.cellier.aka.nice at gmail.com> wrote:
> 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
>
>



-- 
Best regards,
Igor Stasenko AKA sig.