Still about methodClass

Marcus Denker denker at iam.unibe.ch
Wed Jul 26 06:48:21 UTC 2006


On 26.07.2006, at 07:36, Klaus D. Witzel wrote:

> On Tue, 25 Jul 2006 17:19:11 +0200, Andreas Raab wrote:
>
>> Klaus D. Witzel wrote:
>>> I could give more [boring] details if that's wanted.
>>
>> Actually, if you want my attention, talk about the new source code  
>> subsystem ;-)
>
> So we'll take branch here, the new source code subsystem topic will  
> get a new thread.
>
>> The method properties discussion is a red herring in my eyes - we  
>> have a functioning version today and if that needs changing or not  
>> is in the eye of the beholder. Personally (having done it both  
>> ways) I strongly prefer the current solution since it has some  
>> nice properties (like that all relevant attributes are reachable  
>> via direct references from the method and therefore garbage  
>> collection will do The Right Thing without additional help; that a  
>> generic copying mechanism doesn't have to know that some vital  
>> parts of compiled methods are stored elsewhere; that extensions  
>> can be done in one place rather than many) but things can  
>> certainly be done differently. Discussing those merits would  
>> require some more data points other than saying "yes, it can be  
>> done" (because I know it can, I have done it before ;-) and would  
>> likely mean some fairly subjective comparisons of what is "nicer"  
>> or "more understandable" or somesuch.
>
> Good points. May I stress that my concern is the *current*  
> *integrity* of
>
> (nil systemNavigation
> 	allMethodsSelect: [:method |
> 		method hasNewPropertyFormat == false]) size
> => 0

All methods have been recompiled to use the new format (with class  
binding in last literal)

> 	
> |x y | x := y := 0.
> nil systemNavigation
> 	allMethodsSelect: [:method |
> 		method literals last isVariableBinding
> 		ifTrue: [x := 1 + x]
> 		ifFalse: [y := 1 + y]. false].
> x @ y => 49487 at 0
> 	
> |x y | x := y := 0.
> CompiledMethod allInstancesDo: [:z |
> 	z literals last isVariableBinding
> 		ifTrue: [x := 1 + x]
> 		ifFalse: [y := 1 + y]].
> x at y => 49035 at 5
>
> (note the discrepancy, 49487 versus 49035,

non-locally intalled traits methods.

> 0 versus 5, relative to 3.9#7048)
>

There are some methods on the stack that have not yet finished  
executing... should be fixed.
  It's on the never-ending list of stuff on the todo.

> As discussed with Marcus last night (1st Squeak Stammtisch in Bern,  
> 4 Squeakers :) I'm no longer in opposition to how and where  
> MethodProperties are stored and maintained. And if I understand  
> your comment above correctly, that item is hereby closed.
>
> But aCompiledMethod methodClass (aMethod literals last  
> isVariableBinding) must be solved (and perhaps the related  
> implementation must be reviewed) before I'm interested in going a  
> step further into the direction of a new source code subsystem. My  
> intention here is that there is consensus on WHO exactly tells  
> which class a method belongs to; when can (if at all) that change;  
> how are obsolete methods managed in the future. This must be as  
> reliable as possible, otherwise we can forget about  
> aCompiledMethod>>#= for use in any other (sub)system. No, it's not  
> my intention to invent something which is ersatz (<= WordNet/2.1)  
> for aCompiledMethod>>#=.
>

#= does not take the Class of the method into account, as any client  
for equality would not want that. You want to ask "which methods are  
the same in the system". If we
take the Class into account, you will never find any equeal methods...

> A nice and bad (perhaps no *that* close but nevertheless  
> frightening) example is ChangeRecord>>#methodClass, it asks  
> Smalltalk (regardless of obsolence)...
> words and in a single statement: clean up the #methodClass mess in  
> the image.
>

The whole fileOut / Changes stuff os a huge huge mess. But  
#methodClass in ChangeRecord has not much to do with #methodClass on  
CompiledMethod...

Seriously, the only way to improve the situation is to improve it...  
we had many people telling that only perfect solutions are  
acceptable. Or worthy of Squeak
or something. This is wrong: We need *better* solutions, not perfect  
ones. If we would have just made everything continously a little bit  
better over the last
10 years, we would have quite a cool system now.

The idea of searching for the "perfect" solution only (while letting  
everything rot) is the reason for a lot of what we see now.

        Marcus




-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 3938 bytes
Desc: not available
Url : http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20060726/68088ae3/smime.bin


More information about the Squeak-dev mailing list