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

Eliot Miranda eliot.miranda at gmail.com
Mon May 3 02:17:42 UTC 2010


On Sat, May 1, 2010 at 8:36 AM, Travis Griggs <travisgriggs at gmail.com>wrote:

> On Apr 30, 2010, at 11:32 AM, Hernán Morales Durand 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.
>>
>
>
> I didn't implement them originally,


I came up with the idea and implemented it together with Steve Dahl for
VisualWorks 30 where we first used them extensively for menu augmentation on
package load.  So if you want someone to blame, blame me :)


> I just live with them (happily enough) and make use of them. I'm curious
> what you would do differently? How would you make it so can send a message
> to Behavior X, and fetch me all of the methods that belong to a given
> service? Would you just use method categories? Or maybe just embed literal
> arrays in the CompiledMethod frame, and scan for those? Or pattern match
> something from method comments?
>
> One person once told me that they were fine with the idea of annotating
> methods with metadata, but they didn't feel it belonged in the method
> syntax, that it should be a separate pane or something, is that your take as
> well?
>
> If so, I can only offer some thoughts as to why it ended up the way it did.
>
> I guess it was partly because there was already precedent for seeing
> something there with the <primitive: xxx> construct.


That's right.  But it also means that pragmas^H^H^H^H^H^H^Hmethod tags can
be specified in a source file in.  Whole talk of using UI mechanisms to
separate method tags from methods might seem attractive it seems to me
overcomplicated and unhelpful.  A key idea with method tags is to associate
them with specific methods (because the method tag is about the method in
which it occurs) and since methods are specified textually a method tag's
definition belongs in the text of the method.  COmplicating browser UIs and
vastly complicating the addition of method tags to methods brought in from
source files seems to me to be a bad idea.


It was known most developers weren't complaining about that, so use it a
> little more. Language developers aren't necessarily tool developers either,
> so when presented with the option of
>
> a) writing new UI tools to have composite panes to edit the different
> aspects of methods
>
> or
>
> b) hack the compiler/scanner to generalize the <primitive: construct>
>
> the second was probably a much more palatable approach.
>

I think that's unfair.  It was much simpler and reliable to keep them in the
method.  It was expedient to use the <> escape syntax because it existed
already and so we didn't have to extend the language or break old code
adding method tags.  Personally I think it worked out quite well.


> Ironically (to me), there's already a precedent for this, before any <>
> discussion ever existed. There's already two pieces of related, but
> independent data squished together in the same chunk of text. The method
> signature at the top of a method is not really part of the method. You can
> copy/paste the body past the signature of a method into a workspace and
> inspect/doit. But if you include the Smalltalk looking signature from the
> top, it won't work, there's no lvalue and there's no statement terminator.
> In fact, the object that results from compiling the method syntax, it
> doesn't itself even know what it's selector is, but can only answer it for
> you, by going back to it's mclass and asking what signature it's got the
> method registered under. Taken to an extreme, we could argue these two texts
> don't belong in the same pane either.
>

Again saying the selector isn't part of the method strikes me as wrong.  A
method has a signature, which is the selector pattern (including arguments)
at the start, and a body, just as e.g. a C function has a signature and a
body.  People have a head and a body.  Just because a method is a compound
doesn't make elements of the compound not parts of the compound.  A class
has methods.  Without methods it isn't a lot of use.

There are contexts in which extracting the selector (and comment) and not
displaying the method makes sense (API doc).  But in general keeping the
method's head in contact with it's body is a simple way of keeping the
method alive and useful.

HTH
Eliot


> --
> Travis Griggs
> Objologist
> Light travels faster than sound. This is why some people appear bright
> until you hear them speak...
>
>
>
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20100502/8fff9a9b/attachment.htm


More information about the Squeak-dev mailing list