From MethodProperties to Pragmas

Marcus Denker denker at
Fri Jan 20 21:16:17 UTC 2006

On 20.01.2006, at 21:40, Lukas Renggli wrote:
> - Every compiled method has got a dictionary that is lazily
> initialized, as with your original approach.
> - However those properties will be not related to the source-code
> anymore, they can be solely used as a replacement for
> instance-variables, e.g., they do not map to things like <key: value>
> and they disappear if the method gets recompiled.

> - Moreover the keys of properties do not show up as answer to
> #hasLiteralThorough:, since this does not make sense in my opinion if
> the user can't see them in the source.

> - Pragmas will be implemented on top of this with the key #pragmas. I
> have some optimizations in mind that avoids unnecessary allocations
> and that will make searching and accessing pragmas almost as fast as
> with the original approach. Pragmas will show up in the result of
> #hasLiteralTrough: since they are visible in the source-code.

> Does that make sense?

Yes, that looks like exactly what's needed.
> I will publish a new change-set tomorrow afternoon. I am almost there.
> Luckily we have both tests, so we can check if what we want still
> works ;-)


> PS: Why not put the whole #who-array #( class selector ) into the last
> literal?

Methods with super sends in them need to store the class binding in the
last literal. That's where the vm then knows which method to call.
(send, with lookup starting in the super of the class encoded in the
last literal).
So the content of the last literal is fixed as soon as you have any
super send in the method.

> Unfortunately #hasLiteral: returns wrong results, e.g., for
> class-references it returns all methods of the class itself. Since
> #hasLiteral: is implemented as a primitive it cannot be fixed easily
> not to iterate over the last two elements.

Yes, that's why senders calls
Behavior>>whichSelectorsReferTo: literal special: specialFlag byte:  
which filters out hits on the last literal.

> PPS: Another problem with that last literal is that the methods of a
> class point to a wrong value if the class gets renamed. Is this
> intentional?

Intentional not, but unavoidable. We would need to change the class
rename and the method install routines to set the class correctly.

And we need to take care to have Traits behave correctly...  
in Traits should return the Trait. So we need to take care with Trait
methods that contain super-sends...

> Why is #who and #selector not using the last literal?

In my image, they do. I have not come around to move that over.
I'm now making another pass over the ClosurCompiler to move everyting
inside the image that we want there. Especially merge all overrides.

> Hehe ... I am getting into CompiledMethods ;-)


I have to admit I am quite clueless of why there was no iteration on
making all that a bit more general and late-bound in the early phase
of Squeak development... if CompiledMethods would be real objects,
everything would be so much cleaner.


More information about the V3dot9 mailing list