sq 3.9 compiledmethod #sourceClass and #methodClass
Klaus D. Witzel
klaus.witzel at cobss.com
Tue Oct 10 08:29:10 UTC 2006
what happened after
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.
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
> 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.
More information about the Squeak-dev