[squeak-dev] Re: <Method Tags> (Pragmas)
casey.obrien.r at gmail.com
Fri Apr 30 07:53:38 UTC 2010
W00t! The word 'pragma' completely confused me. It made me think Perl
pragma. Annotation to my ear (and this may just be me) implies more than
what these things do. When I hear the word annotation, I think of something
more like a class comment.
Tag is a perfect word for it. Please let's call them tags sooner than later!
I hope it sticks.
On Fri, Apr 30, 2010 at 12:00 AM, Travis Griggs <travisgriggs at gmail.com>wrote:
> 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 <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.
> 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 object.
> 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')>
> labeleled: 'Blah';
> group: 'Whatever';
> 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
> 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.
> Twice now.
> Good stuff.
> Discovery good.
> Piggybacking other stuff into the discovery packet, bad. :)
> Travis Griggs
> "I did not have time to write you a short program, so I wrote you a long
> one instead."
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Squeak-dev