[squeak-dev] Re: <Method Tags> (Pragmas)
travisgriggs at gmail.com
Fri Apr 30 07:00:14 UTC 2010
On Apr 29, 2010, at 8:23 PM, Andreas Raab wrote:
> 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
>> 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
>> 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.
I think it's more fundamental than that. It's that if you're not
careful, you end up with a tag that's trying to serve two masters.
It's trying to be something that can be used to discover the method,
and at the same time encode the construction of a seemingly simple
Or maybe another way to put it is this. No idea if I can make this
make sense. A tag is about meta data. It is very cool that in and of
itself, it is a Smalltalk message syntax. It's a message about the
message. As long as it is strictly about the real method, then to me,
that makes sense. It fits in the meta sense. But when what I really
have, is two pieces of behavior, one which describes a UI element, and
another which describes something associated with the behavior, then
that type of construct belongs in Smalltalk, where it's methods all
the way down, where we implement mixtures of messages all the time.
What happened with the Menu stuff, and what it appears may happen with
your preferences stuff, at least from my cursory reading, is that you
end up using the <tag> as a way of coupling two co-equal pieces of data.
For example, the menu stuff evolved over time to look like:
But why not the other way around?
<menuMethodAction: #selectorToSend receiverAspect:
#messageToGetReceiver arguments: #(#literal 'arguments')>
I could just as easily write an AutomaticMenuAugmentationCementMixer
that worked just as well this way. Instead of limitations about what
kind of UI's I could wrap around the action, I would have traded it
for limitations in what kind of action I could express for my menu
item object. Or I could have split it another way.
> 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:
I'm not sure what your threshold for "small" would have been. Before
we added the last and final <menu method tag> to "rule them all",
VisualWorks had reached no less than 13 variants of the tag, with no
end in sight. We were needing more. I'm reasonably sure that it didn't
start out with 13, it started out with just a "small set", a sort of
quick and easy shorthand for "the common cases."
One problem with this sort of 4GL'ification that was layered on top of
VisualWorks 1.0 in this and other areas, was that you create an
interesting dilemma for the programmer. There's two different ways of
defining a Menu action now. I can go the supposed easy way with a
quick tag shorthand notation, or I can send real messages. When do I
choose which approach? How do I know when to give up on the one, and
switch to the other? How do I swap back and forth? IMO, the effort is
usually better spent making your API simple and easy to discover and
use messages all the way down.
Piggybacking other stuff into the discovery packet, bad. :)
"I did not have time to write you a short program, so I wrote you a
long one instead."
More information about the Squeak-dev