[squeak-dev] <Method Tags> (Pragmas)

Hannes Hirzel hannes.hirzel at gmail.com
Thu Apr 29 22:21:11 UTC 2010

I like the name <method tag>.
I have been checking out definitions for pragma today and the way it
is used is in connection with compiler directives. The name as such
refers to 'pragmatic information' which actually would have the wider
meaning we want to use it for.

However the name <method tag> avoids problems. And people will feel at
ease because of the < > bracket notation.

So topic is not dead at all. To the contrary: Andreas has been busy
today with the Pharo community to work on <method tags> for
preferences. That we get a compatible solution. (details see Pharo

Your points are well noted.
Yes it is tempting to grow micro-DSLs with <method tags>.

The challenge is now to get a good solution.


P.S. From the link cited below

Menu Items Are Objects Too


The remark at the end should be put in BOLD
There is a "trap" that we seem to fall in repeatedly with these method
tags. We try to program with them. Every experience I have like this
convinces me that this is a bad idea. We should program with
Smalltalk. We should use tags simply to annotate simple meta data to a
given method.

On 4/29/10, Travis Griggs <travisgriggs at gmail.com> wrote:
> 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

More information about the Squeak-dev mailing list