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

Travis Griggs travisgriggs at gmail.com
Sat May 1 15:36:43 UTC 2010


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

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.

--
Travis Griggs
Objologist
Light travels faster than sound. This is why some people appear bright  
until you hear them speak...







More information about the Squeak-dev mailing list