2009/10/21 Andreas Raab <andreas.raab@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.