On 4/29/2010 1:23 PM, Travis Griggs wrote:
> Weighing in on a 2 day dead topic is probably passe` around here... :)

It's not quite dead yet :-)

> 2) I push, at ever juncture I can, the term <tagged methods> and <method
> tags>. The <tag> term grew on me for a set of reasons.

I think that's a great term. It doesn't have the compiler connotations 
of "pragma", is shorter than "annotation" yet very concise and flexible. 
I like the sound of, e.g., "the apicall tag instructs the compiler to 
generate the code for some FFI call", "the preference tag allows 
discovery of preferences", the "type tag can be used to annotate 
variables". It really works for me.

In fact, I raise my hand and vote for renaming Pragma to MethodTag :-)

> 3) You can get carried away with <method tags>. It's tempting to grow
> little micro-DSLs with these things. They don't scale well for that.
> They're far from turing complete, and you're limited to literal objects.
> Best example of this is the nightmare that the method tags for menus
> were turning into VW. I wrote about this here:
>
> http://www.cincomsmalltalk.com/userblogs/travis/blogView?showComments=true&printTitle=Menu_Items_Are_Objects_Too&entry=3354355944

I've discussed this particular issue with Eliot at length in order to 
understand what caused these issues. I agree with the conclusion that 
it's dangerous to use method tags as DSLs, and that if the level of 
fine-grained control one needs reaches the level you're describing in 
your post, tags are not the solution.

However, that doesn't preclude their use for a small set of menu 
declarations that we'd like to support going forward. Read the full 
argument here:

http://squeakingalong.wordpress.com/2010/04/27/annotations-for-service-discovery/

Cheers,
   - Andreas