Hi Travis,

Why do people need or want a different syntax for just another new
object? I imagine one day where Smalltalk programmers are forced to
write methods like:

>>selector

   <menu ...>
   <primitive...>
   <documentation ... >
   <test ...>
   <.. put any meta "annotation" you like here ...>

   ...and finally Smalltalk code .....

In this tag-oriented world, I don't like to write tags, if that were
the case I would switch to Java and all those XML they love so much.
Note that changing language it's not just changing syntax, it's a new
form of connectionism thinking which entails loss of knowledge, even
in nonnatural languages.

Hernán

2010/4/29 Travis Griggs <travisgriggs at gmail.com>:
> 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
>
>
>
>
>
>
>
>