On 10.10.2006, at 10:29, Klaus D. Witzel wrote:

> 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.
>

" every CompiledMethod's methodClass's methodDict includes the method  
(itself)." is true even when "methodClass"
returns the Trait in all cases. (as the method is installed in the  
trait".
What is false right now is "every CompiledMethod's methodClass's  
methodDict includes the method (itself) and is contained in
no other methodDict".

I think the stup we have right now should already be setup to return  
the Trait on methodClass: This is the only case where
the method is installed for real, so methodClass is set at that  
point. The sharing-entry that happens when a Trait gets included
in a class does not re-set the methodClass (I think, should be  
checked). So a "methodClass" returns a class or a Trait. if it returns
a Trait, this trait then can be queried for all classes that it is  
installed in.

    Marcus

> /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
>>
>>
>
>
>