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

Igor Stasenko siguctua at gmail.com
Wed Feb 3 11:17:10 UTC 2010

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.

More information about the Squeak-dev mailing list