Ken.Dickey wrote:
> 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?

Mostly that it's generally hard to change the VM and asking for extra 
header bits is generally frowned upon because they are in short supply. 
So in short, yes what you are proposing would be one possible solution 
but by and large it will be *much* simpler to just not share trait 
methods (which is a fix that can be implemented without VM mods).

Cheers,
   - Andreas

> 
> -KenD
> 
>> Message: 7
>> Date: Wed, 21 Oct 2009 09:41:08 +0200
>> From: Adrian Lienhard <adi-cTM//Nd5/DIfv37vnLkPlQ at public.gmane.org>
>> Subject: Re: [Pharo-project] [squeak-dev] Re: Issue with traits
>> To: The general-purpose Squeak developers list
>>         <squeak-dev-bD51WKytQuJI8mQ4nJOOf3xJsTq8ys+cHZ5vskTnxNA at public.gmane.org>,        Pharo Development
>>         <pharo-project-bM+ny+RY8h+a+bCvCPl5/gCzwTLBPCX0 at public.gmane.org>
>> Message-ID: <3C7E5C51-21A8-483A-81A0-40854430A43B-cTM//Nd5/DIfv37vnLkPlQ at public.gmane.org>
>> 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