Hi Marcus,

on Mon, 24 Jul 2006 12:11:31 +0200, you wrote:
> On 24.07.2006, at 11:54, Klaus D. Witzel wrote:
>
>> Hi Marcus,
>>
>> since every other project (package) depends on the integrity of the
>> source code mechanism, I hereby volunteer to get a new source code
>> subsystem (incl. code history) done during this summer. We have no
>> time to wait for a new (reliable, scalable, available) source code
>> mechanism, so I intend to make resources available for this project.
>>
>
> Good! But we should not wait with 3.9 for this.

O.K.

>> Here's a draft for a new source code subsystem:
>>
>> 0] (digit for Wolfgang ;-) there are at least three preferences:
>>
>> 1] use the traditional subsystem as is
>>
>> 2] use Dan Ingalls Source Compression as suggested earlier
>>
>> 3] use a service based (network based) mechanism
>>
>> I've studied the recent additions which where made to
>> CompiledMethod w.r.t. MethodProperties, this has to be cleaned up
>> before anything else can be done.
>> 	No, I'm not a friend of storing any MetaData *in* the meta data's
>> object.
>
> By the selector of a Method is not "meta"!

I'm sorry it is "meta" by tradition. Otherwise it would have been stored  
in the method (literals) since the 80's of the previous century. And if  
you cannot agree with that view:

only the VM knows about the relationship between the selector used for  
method lookup and the found and executed method. This *is* what meta is  
about, that's what I think.

> Every method should have a
> name, and if you want a method with another name, make a new method.

No clash here: if I throw the MethodProperties oop out of CompiledMethod's  
literals then I can still fulfill this your requirement (and you owe me a  
beer ;-).

> Even the very idea of
> different names for the same method is not a good one, as the name is
> hard-coded in the sourcecode, too. It's a direct, non-meta property
> of the method object.

Sorry (same argument as above). It is, and I have to agree, a  
*substantial* part of the source-to-compiled method messenger "RNA"  
enzymatic process. But the result cannot tell which name its gene had for  
it (we human beings can, same for source/compiled code, to some extent).  
Take as a counter example #DoItwith:with:... and the cause for having  
CompiledMethod>>defaultSelector.

But anyways, I do not see a clash here and it's only a matter  
implementation.

Having said that, was is really missing is " an  
ObsoleteCompiledMethod(4711) ", mantained by MethodDictionary with key :=  
oldMethod and value := aClass -> aSelector. A new global variable  
ObsoleteCompiledMethods can hold, with advantage, an instance of  
WeakIdentityKeyDictionary for these keys and values.

>> I propose to put the MethodProperties into the MethodDictionary
>> where they belong (same method can *and will* have different
>> properties per class
>
> Methods should be only installed in one class.

And the system should be transparent if not so. But again, it can be  
implemented the way you describe.

> yes... Traits, sigh...
> the copying of Traits is evil... I think a better model for traits
> would have been to share Bytecode,
> not Methods. But then in Squeak these two concepts have been mangled
> into one for space reasons, which was a bad idea in general. (Or: It
> was a bad idea not
> to harvest Tims fix in 1998...).

I have no problem with this. This will (perhaps) be reviewed once people  
take advantage of Squeak Trait(s).

>> = one MethodProperties in each class' method dictionary). As a
>> consequence, today's MethodProperties would all be garbage
>> collected (except for the few pragmas), because all they store is
>> the selector. And CompiledMethod>>#selector is resolved by
>> #methodClass and #keyAtValue: so #who can disappear as is intended.
>>
>> After that, the *new* source code information can be put into the
>> new MethodProperties, which allows an easy migration because the
>> old source code pointer won't be touched until after migration.
>>
>
> You can do that even in the current structure. The sourcePointer is
> now per Method, too.

? I was referring to the old (as is now) and, at the same time, during  
migration, to the then new sourcePointer, with emphasis on having both  
available during migration. What was it what you meant?

/Klaus

>
>        Marcus