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