Still about methodClass

Klaus D. Witzel klaus.witzel at cobss.com
Wed Jul 26 05:36:18 UTC 2006


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
	
|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, 0 versus 5, relative to  
3.9#7048)

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

A nice and bad (perhaps no *that* close but nevertheless frightening)  
example is ChangeRecord>>#methodClass, it asks Smalltalk (regardless of  
obsolence)...

In other words and in a single statement: clean up the #methodClass mess  
in the image.

Thereafter we can introduce (and/or reuse) concepts which support a source  
code view on current, obsolete, historized and future CompiledMethods, a'  
la distributed authoring and versioning.

Please nobody misunderstand me here: propose a fix for #methodClass  
(obsolete methods as well) and we can immediately turn over to the more  
interesting things like managing the future (so to speak).

> In light of that, I'd rather discuss an area that actually needs fixing,  
> like the source code subsystem.

Me too; let's fix first things first.

/Klaus

> Cheers,
>    - Andreas
>
>





More information about the Squeak-dev mailing list