Ok, and still not convinced at all the advantages of that approach
over normal message sending. What's the real limitation of common
objects for implementing a "discovering mechanism"? It's simply
another subsystem, it could be easier or harder than others, but I'm
sure you don't *need* to use already weird syntax to implement it.
All the tags stuff smells like people wanting to experiment "cool
things" with DSL's but is using us as testers.

Hernán

2010/4/30 Hannes Hirzel <hannes.hirzel at gmail.com>:
> 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
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>
>>>>
>>>
>>>
>>
>>
>
>