sq 3.9 compiledmethod #sourceClass and #methodClass

> So far as I can see the method CompiledMethod>sourceClass is now
> completely obsolete and its function is replaced by methodClass.
> Since the 3.9-7061 image seems to have all methods set up to have the
> methodClass is there any value in this potentially confusing extra
> function?
>
> 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?

> 2006/10/10, tim Rowledge <[hidden email]>:
>> 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?

>
> On 9-Oct-06, at 10:08 PM, Philippe Marschall wrote:
>
>> 2006/10/10, tim Rowledge <[hidden email]>:
>>> 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.

> 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 <[hidden email]>:
>>>> 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
>
>

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

> /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 <[hidden email]>:
>>>>> 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
>>
>>
>
>
>

> 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 <[hidden email]>:
>>>>>> 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
>>>
>>>
>>
>>
>>
>
>
>

> 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 Denker wrote:
>> I think the setup we have right now should already be set up 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.
>
> Not necessarily true. A method which includes a super-send cannot  
> point to the trait in its method class - if it did it would explode  
> right under your feet.
>

>> The sharing-entry that happens when a Trait gets included
>> in a class does not re-set the methodClass (I think, should be  
>> checked).
>
> That better not be true for methods with super sends.
>
>> 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.
>
> This seems wrong. It should always return the class it *installed*  
> in, never the trait it is *defined* in.
>

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

>
> The fun thing is that the CompiledMethod special treatment was done  
> to save space (rightly, there are lots of methods!).
> But then, when there is more RAM, people tend to like the idea of  
> trading RAM for more powerful abstractions. e.g having
> classes now their class and name. In the end, we are soon at a  
> point where the specia treatment of CompiledMethod does
> not save memory, but it costs memory for all the hacks build around  
> it to support what we would get for free if it would be
> a standard object... so having CompiledMethods be normal Objects is  
> definitly the right thing (which it was in 1998 already,
> I might add).

>
>> 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.
>
> Yes, I think that having the method include the method class is  
> essentially the same barrier to cm sharing (until 1) above) as  
> having a super in the code. Is it practical to fix this very soon?  
> Obviously the code to cope with a non-shared trait method is in  
> place so could we just kill the shared case for now and re-wiggle  
> the currently shared cases?
>