sq 3.9 compiledmethod #sourceClass and #methodClass

Klaus D. Witzel klaus.witzel at cobss.com
Tue Oct 10 09:13:04 UTC 2006

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.


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

More information about the Squeak-dev mailing list