Hi Travis,
Thanks for your answer, some somments between lines
2010/5/1 Travis Griggs travisgriggs@gmail.com:
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?
To me is not important who implement them but it is valuable to talk, learn and think about the consequences of adopting ideas not only at the convenience level, but at the whole picture level, these language issues affect how systems are thought, our perception of how things work, affect system's identity and in the end, to us as a social phenomenon.
Let's take an example with some rhetorical questions, if this line of adoption continues and some ST authority one day embeed in Smalltalk one of the many XML query languages, then still would be Smalltalk or it would be a reflectaphore of Smalltalk? And if later he embeed the most fashioned languages today, then it would became a mutant (or "variant" of what was once long time ago) ? I'm not doubting of the usefullness of a solution now for today's world problems, but it is simply too much solution developer narrative (read: tired of reading a particular kind of discourse), like if the community were stuck into a social dynamics open source book and arguments (thinking) were losing value in favor of... packages.
That's one of my problems with some (XXX) embedded solutions too. Again, XXX should be supercool for solving some problems, but why do not question its ideas beyond the majority rule and meritocracy *before* adopting it? We may ask: How many real systems were implemented using XXX ? What parts were changed and how? How many time took to the developers to learn and get used to program with XXX ? To what discourse belongs the solution what propose and proponents? There is a (hidden) scientific discourse? then take a note of the main units of work of scientific production: Research. There is a cultural or business discourse? etc.
Sorry for not offering you a clear alternative solution, there should be many creative ways to do it. I've seen a system with literal arrays embedded in the CompiledMethod frame for solving i18n at the tools level, i.e., without affecting the syntax or traditional developer tools but providing specialized browsers for automatic translation.
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.
Exactly, I was suprised the first time I've seen the links between MethodDictionary, CompiledMethod, sources, etc. And if you take a look at "low level" things like Multi-Methods, MethodWrappers, Instance-Based behavior, etc. I wonder why most developers (I know) still sees it in the form of hack tools and not as a natural way of working with a true reflective system. If you need hacks to implement new behaviors, then possibly the subsystem base design is not good enough.
Hernán
-- Travis Griggs Objologist Light travels faster than sound. This is why some people appear bright until you hear them speak...