2009/10/21 Andreas Raab <andreas.raab at gmx.de>:
> Igor Stasenko wrote:
>>
>> now what i found interesting:
>>
>> (ABBAB methodDict at: #foo) == (ABBAC methodDict at: #foo)
>>
>> but as side effect, we got this one:
>>
>> (ABBAB methodDict at: #foo) methodClass  ==> ABBAC
>>
>> which i find a bit disturbing :(
>
> Yes, seems wrong. VERY wrong. Try this:
>
> Object subclass: #BaseA
>
> BaseA>>foo
>  ^42
>
> Object subclass: #BaseB
>
> BaseB>>foo
>  ^13
>
> And then create subclasses of BaseA and BaseB which use your trait and have
> the trait implementation use "^super foo". One of two things should happen:
>
> a) They both return the same (incorrect) value (which would be expected if
> methodClass is the same). In this case it's just plain broken.
>
> b) They both return different values, in which case there is code that
> handles super sends specifically and the sharing is simply an unnecessary
> optimization.
>
> I hope it's the latter case which would mean you only need to throw out the
> test for super sends and do whatever that code was doing to begin with ;-)
>

Ouch... so VM behavior depends on correct methodClass slot. Thanks for
reminding!
I remember that methodClass plays important role (and its important to
have method and its
methodClass being in sync with class where the method installed), but
forgot the details :)

That could lead to even worse results, if you use super sends, and then
in base class , accessing the instance variables in base method. It
could corrupt the memory & crash the VM.

I hope this is already fixed, because the image where i checked it
is quite old one - 3.10.2

> Cheers,
>  - Andreas


-- 
Best regards,
Igor Stasenko AKA sig.