Hi Travis,

Thanks for your answer, some somments between lines

2010/5/1 Travis Griggs <travisgriggs at 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...
>
>
>
>
>
>