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."