Fwd: From MethodProperties to Pragmas

[Lukas Renggli]

Hi Marcus,

> But one thing is *essential* for me: I need an interface for storing state
> in compiledMethods, things that do not appear textually as pragmas but
> that you would normally do with intance variables (if Squeak would
> allow them...).

ok I see your point. What we have both in mind is something very
different and it probably makes sense to keep both approaches
separate, the properties and the pragmas. Forget about the change-set
I posted, I will go through the whole thing again a post a new
solution, that is optimal for both of us:

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

> I will check how to merge those two things. e.g. why not keep
> the idea of properties and put the Pragmas into a property?
> Empty pragmas should take no space here, too. Of cource
> non-empty ones would be a bit less efficient, as they would
> mean to have a PropertyDict and the collection of Pragmas.

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

Cheers,
Lukas

PS: Why not put the whole #who-array #( class selector ) into the last
literal? 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.

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? Why is #who and #selector not using the last literal? Why
is there no accessor #actualClass?

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

--
Lukas Renggli
http://www.lukas-renggli.ch