Why not share the code? Â Just use a "cell" to hold the class and have methodClass accessor do the indirection. If you have a bit in the method header, the VM could use it as a 0/1 index into the code to call to do (or not do) the extra indirection. Â Just think of the a trait method as a closure which is parameterized on the class. Am I missing something deep here? -KenD
Message: 7 Date: Wed, 21 Oct 2009 09:41:08 +0200 From: Adrian Lienhard <adi@netstyle.ch> Subject: Re: [Pharo-project] [squeak-dev] Re: Issue with traits To: The general-purpose Squeak developers list         <squeak-dev@lists.squeakfoundation.org>,        Pharo Development         <pharo-project@lists.gforge.inria.fr> Message-ID: <3C7E5C51-21A8-483A-81A0-40854430A43B@netstyle.ch> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes
I've fixed this issue in Pharo a couple of months ago. CompiledMethods  are not shared anymore, so methodClass returns the expected class. At  the time I implemented traits (2004?), there were no method properties  and hence sharing compiled methods worked -- of course except for  super sends in which case the method was always recompiled (so the  answer to Andreas' question below is b)).
Cheers, Adrian