<br><br><div class="gmail_quote">On Sat, May 1, 2010 at 8:36 AM, Travis Griggs <span dir="ltr"><<a href="mailto:travisgriggs@gmail.com">travisgriggs@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<div class="im">On Apr 30, 2010, at 11:32 AM, Hernán Morales Durand wrote:<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Ok, and still not convinced at all the advantages of that approach<br>
over normal message sending. What's the real limitation of common<br>
objects for implementing a "discovering mechanism"? It's simply<br>
another subsystem, it could be easier or harder than others, but I'm<br>
sure you don't *need* to use already weird syntax to implement it.<br>
All the tags stuff smells like people wanting to experiment "cool<br>
things" with DSL's but is using us as testers.<br>
</blockquote>
<br>
<br></div>
I didn't implement them originally, </blockquote><div><br></div><div>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 :)</div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">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?<br>
<br>
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?<br>
<br>
If so, I can only offer some thoughts as to why it ended up the way it did.<br>
<br>
I guess it was partly because there was already precedent for seeing something there with the <primitive: xxx> construct.</blockquote><div><br></div><div>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.</div>
<div><br></div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"> 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<br>
<br>
a) writing new UI tools to have composite panes to edit the different aspects of methods<br>
<br>
or<br>
<br>
b) hack the compiler/scanner to generalize the <primitive: construct><br>
<br>
the second was probably a much more palatable approach.<br></blockquote><div><br></div><div>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.</div>
<div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<br>
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.<br>
</blockquote><div><br></div><div>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.</div>
<div><br></div><div>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.</div>
<div><br></div><div>HTH</div><div>Eliot</div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"><font color="#888888">
<br>
--<br>
Travis Griggs<br>
Objologist<br>
Light travels faster than sound. This is why some people appear bright until you hear them speak...<br>
<br>
<br>
<br>
<br>
<br>
</font></blockquote></div><br>