On 10.10.2006, at 11:20, Andreas Raab wrote:

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

Ups, yes, minus those methods with super sends.

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

But right now (when there is no super in it) those are all the same  
method. (Methods are shared for saving
space).

So the solution would be to never share, allways copy. The machinary  
now used for super send methods should
be used for all methods, and we are done.

Space saving then can be added again after we make CompiledMethods  
normal objects (with a ByteArray containing
the Bytecode another array for the literals). Then these can be  
shared to save space, while the Method itself will be
a copy.

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

What should have been in in the 90ties would have been a "Squeak  
revisited", a simplifcation and generalisation pass, based
on the fact that the world was different in 1997 than it was in 1977.  
A more simple and general system of course makes it much
easier then to re-start hacking and experimenting (e.g. for eToys),  
thus it is even the right thing to do from a "Kids first" perspective.
That sadly never was done, work done in that direction was even  
completely ignored and rejected.

     Marcus