[squeak-dev] Re: <Method Tags> (Pragmas)
andreas.raab at gmx.de
Fri Apr 30 03:23:47 UTC 2010
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:
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
More information about the Squeak-dev