Request for Comment: MethodAnnotations for 3.9alpha
Andreas Raab
andreas.raab at gmx.de
Sun Aug 28 22:50:19 UTC 2005
Alejandro F. Reimondo wrote:
> Hello Marcus, and all;
>
> The properties can be implemented for all objects
> (e.g. Digitalk's Smalltalk saga has had implemented
> for +10years, and it is proved to be helpfull).
> If done this way, CompiledMethods will not be
> "special objects"... with properties :-)
Unfortunately, this also has some significant impacts on GC behavior.
This is well-known and lead to the invention of Ephemerons in
VisualWorks. Unless you have something like Ephemerons you can get
bitten in very weird ways.
>>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):
>>
>>Object>>mumble
>> <hello: 4>
>>
>>Tweak uses these annotations to describe when a method should be
>>activated.
>
> mmm... why to use a "primitive" mechanism?
>
> mumble
> ^thisContext method propertyAt: #hello
> (or something like this using only objects and no syntax/architecture sugar)
An annotation is called an annotation because it has no sematic effect
for the execution of the method. What you have in your method is not an
annotation but *code* (which does have an effect). To illustrate:
Object>>yourself
<returns: Object>
^self
Here, we have annotated the Method Object>>yourself with a sample
annotation to indicate the type of the return value. We could retrieve
this type by using:
(Object compiledMethodAt: #yourself) propertyValueAt: #returns.
But the annotation does not change the execution of the method one bit.
The method is still the same (a "quick return self"), the byte codes
haven't changed.
Cheers,
- Andreas
More information about the Squeak-dev
mailing list
|