In theory this could be solved from other end.

Actually, VM could capture the class object (where it took a
particular method from)
during lookup procedure. It could place the class oop reference into a
method's activation record (context).
Then compiled method would not be obliged from holding a reference to
a class where it is installed to and super send
semantics would not be affected by (in)correct data in compiled
method. But this means that each context should carry additional slot
- class object, which means extra space, and consequentally a bit
slower message sends performance. Given that super sends happen happen
quite infrequently, comparing to normal sends, this scheme seems less
practical than existing one.

On 3 February 2010 13:06, Igor Stasenko <siguctua at gmail.com> wrote:
> 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.
>



-- 
Best regards,
Igor Stasenko AKA sig.