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. <div>
<br></div><div>Tag is a perfect word for it. Please let's call them tags sooner than later! I hope it sticks.<br><br><div class="gmail_quote">On Fri, Apr 30, 2010 at 12:00 AM, Travis Griggs <span dir="ltr"><<a href="mailto:travisgriggs@gmail.com">travisgriggs@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"><div class="im"><br>
On Apr 29, 2010, at 8:23 PM, Andreas Raab wrote:<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
On 4/29/2010 1:23 PM, Travis Griggs wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Weighing in on a 2 day dead topic is probably passe` around here... :)<br>
</blockquote>
<br>
It's not quite dead yet :-)<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
2) I push, at ever juncture I can, the term <tagged methods> and <method<br>
tags>. The <tag> term grew on me for a set of reasons.<br>
</blockquote>
<br>
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.<br>
<br>
In fact, I raise my hand and vote for renaming Pragma to MethodTag :-)<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
3) You can get carried away with <method tags>. It's tempting to grow<br>
little micro-DSLs with these things. They don't scale well for that.<br>
They're far from turing complete, and you're limited to literal objects.<br>
Best example of this is the nightmare that the method tags for menus<br>
were turning into VW. I wrote about this here:<br>
<br>
<a href="http://www.cincomsmalltalk.com/userblogs/travis/blogView?showComments=true&printTitle=Menu_Items_Are_Objects_Too&entry=3354355944" target="_blank">http://www.cincomsmalltalk.com/userblogs/travis/blogView?showComments=true&printTitle=Menu_Items_Are_Objects_Too&entry=3354355944</a><br>
</blockquote>
<br>
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.<br>
</blockquote>
<br></div>
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.<br>
<br>
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.<br>
<br>
For example, the menu stuff evolved over time to look like:<br>
<br>
arbitraryMethod<br>
<stuff:that:encodes:how:to:wrap:this:behavior:in:a:very:specific:UI:implementation><br>
<br>
self<br>
doSomeLogic;<br>
maybeCheckSomething;<br>
decideWhetherWeShouldContinueToGoOn;<br>
goAndDoSomething<br>
<br>
But why not the other way around?<br>
<br>
arbitraryMethod<br>
<menuMethodAction: #selectorToSend receiverAspect: #messageToGetReceiver arguments: #(#literal 'arguments')><br>
<br>
^MenuItem<br>
labeleled: 'Blah';<br>
group: 'Whatever';<br>
hopefullyYouGetThePoint;<br>
yourself<br>
<br>
<br>
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.<div class="im">
<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
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:<br>
</blockquote>
<br></div>
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."<br>
<br>
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.<div class="im">
<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<a href="http://squeakingalong.wordpress.com/2010/04/27/annotations-for-service-discovery/" target="_blank">http://squeakingalong.wordpress.com/2010/04/27/annotations-for-service-discovery/</a><br>
</blockquote>
<br>
<br></div>
Read.<br>
<br>
Twice now.<br>
<br>
Good stuff.<br>
<br>
Discovery good.<br>
<br>
Piggybacking other stuff into the discovery packet, bad. :)<br><font color="#888888">
<br>
--<br>
Travis Griggs<br>
Objologist<br>
"I did not have time to write you a short program, so I wrote you a long one instead."<br>
<br>
<br>
</font></blockquote></div><br><br clear="all"><br>-- <br>Casey Ransberger<br>
</div>