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
|