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

Hannes Hirzel hannes.hirzel at gmail.com
Fri Apr 30 17:35:06 UTC 2010

The mechanism to discover preferences in method tags <pragma> is in the class

Preferences , class side , category 'dynamic preferences' , method

preference: prefName category: aCategory description: helpString type:

Then look for senders of this method. This gives you the methods with
this tag in it. (38 so far, i.e. the process has just started)


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