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