Request for Comment: MethodAnnotations for 3.9alpha
Andreas Raab
andreas.raab at gmx.de
Sun Aug 28 22:36:15 UTC 2005
Hi Marcus -
> What are MethodAnnotations?
> ---------------------------------------
>
> MethodAnnotations can be seen from two perspectives:
>
> 1) storing state in CompiledMethod objects.
This is good and I wholeheartedly agree with it.
> 2) Syntax for Method Annotations.
>
> We can set annoations to methods using the syntax we already know
> for primitives
> (which are, in a sense, just an annotation):
Let me caution you about this a little. If compatibility is a concern
(and I believe that contrary to Tweak, for many people compatibility is
a major concern here) you may not want to introduce syntax for
annotations lightly. I wonder if (except from Tweak) there is any
existing use for annotation that would *require* syntactical support.
And there isn't you may want to be careful about when and how to
introduce that support.
> Tweak uses these annotations to describe when a method should be
> activated.
Actually no. There is more involved than that and because of it the
compiler has to support it as a syntactical entity (very much like like
the <primitive:module:> syntax which is recognized separately, too).
> How are they implemented?
> --------------------------------------
> Andreas' orginal implemention used a big WeakIdentityKeyDictionary
> in a class var of CompiledMethods to store the IdentityDictionary
> for each method. This turns out to have some nice properties
> (no space is used for non-annotated methods) and a bad one: Performance.
Unfortunately, there is more than one. For example, serializing compiled
methods becomes a tricky issue (the main reason why I need to switch in
Tweak to the new implementation).
> So we hacked a version that used the literealFrame instead, after
> discussing this with Andreas, we now use the second-last literal
> Frame entry. The reasoning is the following: The first one is already
> used for some primitives, the last one encodes the class in the
> case that there is a supersend in the method.
>
> So if we use the last entry to store the class for each method
> (supered or not), we can put the annoations in the one before and
> don't need to test for anything. Putting the class (or Trait) in
> the last litereal has the nice side-effect of making a fast #who
> possible.
Plus: We can also store the selector of a method which is extremely
helpful in various situations and makes #who *blindingly* fast ;-)
Plus: We can trivially remove the awkward encoding of the file pointer
(this immediately gives us an unlimited size for the changes and sources
file).
Plus: We can encode which package a method belongs to right in the method.
...
> The changesets attached are a first step: We are right now adding the
> class binding to all methods but quickmethods (need to fix that), the
> second last literal is initialized with nil and will lazy initalize the
> property dictionary if it's accessed.
Sounds good so far, but can we create a new class
CompiledMethodProperties (instead of using a dictionary), please? The
point being that with further normalization of CompiledMethod we will
almost certainly want to add some iVars and having a dictionary will
require us to do more work for converting from dictionary to an explicit
object etc.
Cheers,
- Andreas
More information about the Squeak-dev
mailing list
|