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

Hannes Hirzel hannes.hirzel at gmail.com
Fri Apr 30 18:38:19 UTC 2010


Actually this <cool thing> has been around for a long time in
VisualWorks and Travis refers to the experience with that in this
thread. May I ask you to go to the blog entry he refers to.

In fact if we go for this as well it should avoid these pitfalls....

--Hannes

On 4/30/10, Hernán Morales Durand <hernan.morales at gmail.com> wrote:
> 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
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>
>>>>
>>>
>>>
>>
>>
>
>



More information about the Squeak-dev mailing list