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 at netstyle.ch>
> Subject: Re: [Pharo-project] [squeak-dev] Re: Issue with traits
> To: The general-purpose Squeak developers list
>         <squeak-dev at lists.squeakfoundation.org>,        Pharo Development
>         <pharo-project at lists.gforge.inria.fr>
> Message-ID: <3C7E5C51-21A8-483A-81A0-40854430A43B at 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