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:
>>>
>>>
>>> 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.
>>
>
> 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:
>
> arbitraryMethod
>
>  <stuff:that:encodes:how:to:wrap:this:behavior:in:a:very:specific:UI:implementation>
>
>        self
>                doSomeLogic;
>                maybeCheckSomething;
>                decideWhetherWeShouldContinueToGoOn;
>                goAndDoSomething
>
> But why not the other way around?
>
> arbitraryMethod
>        <menuMethodAction: #selectorToSend receiverAspect:
> #messageToGetReceiver arguments: #(#literal 'arguments')>
>
>        ^MenuItem
>                labeleled: 'Blah';
>                group: 'Whatever';
>                hopefullyYouGetThePoint;
>                yourself
>
>
> 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.
>
>
>
>> http://squeakingalong.wordpress.com/2010/04/27/annotations-for-service-discovery/
>>
>
>
> Read.
>
> Twice now.
>
> Good stuff.
>
> Discovery good.
>
> Piggybacking other stuff into the discovery packet, bad. :)
>
> --
> Travis Griggs
> Objologist
> "I did not have time to write you a short program, so I wrote you a long
> one instead."
>
>
>


-- 
Casey Ransberger
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20100430/e6ed5fd3/attachment.htm