Hi Marcus,

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

Yeah, that makes sense. kiss.

/Klaus

On Tue, 10 Oct 2006 10:57:18 +0200, Marcus wrote:
> 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
>>>
>>>
>>
>>
>>
>
>
>