What I have understood so far is that these method tags help to decouple things. Instead of my package having to do something (e.g. registering a preference) the base system "discovers" the preference settings of my package.
--Hannes
On 4/30/10, Hernán Morales Durand hernan.morales@gmail.com wrote:
Hi Hannes,
I'm not talking about an instrumentation problem, I'm not having problems with finding things, the comment was intended to note that there whatever you may write with < .. > you may write it with real Smalltalk messages.
It's just a matter of finding the objects, and sometimes, adapting the tools.
Hernán
2010/4/30 Hannes Hirzel hannes.hirzel@gmail.com:
The <...> syntax is already there. In fact since 3.9.
Go to class Pragma in 4.1, bring up the class comment. At the bottom you find the following
To browse ALL methods with pragmas in the system evaluate SystemNavigation default browseAllSelect: [:m| m pragmas notEmpty]
and to browse all nonprimitive methods with pragmas evaluate SystemNavigation default browseAllSelect: [:m| m primitive isZero and: [m pragmas notEmpty]]
These are actually not so many.
You mention an example
<menu ...> <primitive...> <documentation ... > <test ...> <.. put any meta "annotation" you like here ...>
...and finally Smalltalk code .....
Yes this is the direction things seem to head .....
--Hannes
On 4/30/10, Hernán Morales Durand hernan.morales@gmail.com wrote:
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@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.
- 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.
- 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).
- 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&a...
- 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