sq 3.9 compiledmethod #sourceClass and #methodClass

Marcus Denker denker at iam.unibe.ch
Tue Oct 10 07:14:20 UTC 2006


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