2009/10/21 Andreas Raab <[email protected]>: > 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. _______________________________________________ Pharo-project mailing list [email protected] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
