Marcus,

what happened after

-  
http://lists.squeakfoundation.org/pipermail/squeak-dev/2006-July/106543.html

with which we asserted that every CompiledMethod's methodClass's  
methodDict includes the method (itself).

So, reflecting the 3 options you listed below, it ought to be option 2?

I confirm that the above is no longer the case, has something broken again.

/Klaus

On Tue, 10 Oct 2006 09:14:20 +0200, Marcus Denker wrote:
> On 10.10.2006, at 07:33, tim Rowledge wrote:
>> On 9-Oct-06, at 10:08 PM, Philippe Marschall wrote:
>>> 2006/10/10, tim Rowledge <tim at rowledge.org>:
>>>> There is one bit of confusion that seems to be related to the use of
>>>> Traits though -
>>>> (SystemNavigation default allMethodsNoDoitsSelect:[:cm|
>>>>                 (cm sourceClass == cm methodClass) not ]
>>>> produces a list of methods where the two messages produce different
>>>> results. It seems that for example
>>>> Behavior >> #isLocalAliasSelector:
>>>> has a methodClass of 'Behavior' as one might expect but a sourceClass
>>>> of ' TAccessingTraitCompositionBehavior' which I wouldn't expect. Why?
>>>
>>> Because its a method of a trait?
>> Well, sure it's a trait but I don't see why that would be a good reason  
>> for such a split. I might well just be a side effect of the  
>> introduction of method properties for example.
>
> No... so for explanation: Traits share CompiledMethods (if there is no  
> super in them).
>
> So when you asked the (prior to properties) for #who, the answer was  
> random: in what ever class or Traits the method was found first, this  
> was returned as the class.
>
> When I then added properties (and having CompildMethods know their  
> class/selector) the question was: Does this ill-defined #who now mean I  
> can't add
> the class/selector to compiledMethods? It was broken before, and it  
> would be broken after (because shared compiledMethods would have only  
> one, random
> #methodClass). So I could not do the properties/pragmas and wait for  
> Traits to be fixed. Fixing  could be done afterwards, too. So I opted  
> for introducing the fast
> #who that stores class and selector in the method.
>
> For Traits, this now leads to undefined results, as did #who before.  
> This should be fixed, of course. There are three alternatives: 1)  
> allways return the Trait on
> #methodClass, 2) give up CompiledMethod sharing alltogether or 3) have  
> CompiledMethods be real Objects and share the ByteCode ByteArray and the  
> literals.
>
> So.. best would be 3), but this seems to be off for at least 8 other  
> years, so I guess it would be 1) first and later maybe 2, as the  
> CompiledMethod sharing makes
> not much sense as soon as CompiledMethods know something about where  
> they are in the system.
>
>         Marcus
>
>