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