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 at 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 at 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 at 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 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
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>
>>>
>>
>>
>
>