Why does every method get sent a #methodClass:

Marcus Denker denker at iam.unibe.ch
Mon Oct 2 08:58:45 UTC 2006


On 27.09.2006, at 17:19, tim Rowledge wrote:

> Fair enough; so why not include the class in the properties?
>

because we need a place to store the properties... and CompiledMethods
are strange objects (there was a patch from you almost 10 years ago that
fixed that, yes... "Kids first", I guess). So we need to save the  
properties in some
entry of the literal frame. Now the first is already used in some  
methods (when
they have named prims), the last is used sometimes (when there is a  
super).

So we can use either the 1st/2nd or the 2nd last/last, depending on the
layout. Both would need a runtime check, in case of the super-send even
one that has to iterate over all bytecode. So not good.

So Andreas suggested to just put a class binding in the last literal,
regardless if there is a super send ot not. And indeed, this was a  
clever
idea: 1) we have now a fixed offset for the properties (they are  
always in the
2nd last literal and 2) it even costs nothing in space, as we would  
have wanted
to have the method know it's class anyways, so we would have put it  
in a property,
as you suggested.

This now is not the case, which might be not 100% nice, but good  
enough. In a real
OO design, we would have instVars for class and selector in  
CompiledMethod. Having
them as properties is not really a goal in itself.

Properties are nice, but if Morphic told us one lesson: Don't use  
them too much, as
they hide the Design completely and make thus the code un- 
maintainable (they
are like dynamicallky bound variables, just for instVars, not Temps...)
Or does anyone claim to understand BookMorph?

So... next step would be to actually fix the VM to make  
CompiledMethods normal
Objects and clean the mess up even more.


     Marcus



More information about the Squeak-dev mailing list