Weighing in on a 2 day dead topic is probably passe` around here... :)

I can weigh in with some practical/historical experience from  
VisualWorks land, where they originated.

1) We use them more and more. But judiciously. What they are really  
good for is defining programatic categorization of methods, so that  
one can discover programatically subsets of behavior that a given  
Behavior implements. Examples include the obvious <settings..> and  
<menu..> sort of things. We use them in the RefactoringBrowser to make  
certain aspect easily pluggable, such as adding your own tool pane,  
navigator pane, or status pane. The inspector uses them to support  
arbitrary inspector fields on any object. We even use them in <test>s,  
because I've found that you tend to make better test selector names,  
when your brain isn't trying to negotiate coming up with a good  
selector name that describes what your test does AND begins with the 4  
characters 'test'. I used them in production code more and more when I  
was at Key writing UIs and control systems for optical food sorting  
equipment.

Why not just use a method categories (protocols)? Because you can't  
quite put enough information there to make them useful, and they're  
stuck with just one category. You want simplicity and judicious  
application, deferring to good ol' messages as much as possible, but  
simple categories just don't provide enough.

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.  
Technically, they result in "AnnotatedMethods", and one can call each  
item an "Annotation". But that's a big long word, and using small  
short words always keeps things simpler. I also liked the harmony with  
the fact that we live in a world dominated by <tag><markup><languages>  
and they're called tags there. Since we were using roughly the same  
syntax, why not go with it? It's also easier to draw an icon that  
shows up next to methods for <tagged methods> than it is for  
<annotated methods> (see attached pic).

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

4) History repeats itself, I think I wrote a post along these lines,  
about 3+ years ago. I've slept since then tho, so I'm not sure.

--
Travis Griggs
Objologist
"The best way to know you have a mind is to change it" -Judge Pierre  
Leval

-------------- next part --------------
A non-text attachment was scrubbed...
Name: Picture 2.png
Type: image/png
Size: 13233 bytes
Desc: not available
Url : http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20100429/48eb8a42/Picture2.png
-------------- next part --------------