> Cool! I suggest the rewrite:
>
> c.unknownmethod(args) -> c.opDotExp!("unknownmethod")(args)
>
> That way you have the option of handling the method name statically or
> dynamically.
Careful. If you do that, you need to make sure it's possible to invoke
a given method at runtime. Assuming getMembers is implemented (I make
daily sacrifices in hopes of that), each distinct opDotExpr!(s) needs to
get an entry.
Otherwise, you've ironically created something that's HARDER to
programatically invoke. :P
A few more comments.
There seem to be a few arguments being given against this. First is one
of syntax: if this gets in to the language, you won't be able to tell
whether a given member access actually works or not, so it should have a
unique syntax.
The problem with this is that if you do that you might as well not
bother at all; dynamic dispatch objects will never be able to
participate in templates. Unless, of course, you always write templates
using dynamic dispatch syntax, at which point you've just nullified the
benefits of doing so since now you can't tell whether a given call will
work or not until runtime.
It either goes into the language with "normal" syntax and is used
sparingly, or it goes in with special syntax and is either never used
(or when it is used it is limited in where it can be used) or everything
switches over to the special syntax.
As much as I would prefer to see dynamic dispatch have a special syntax
or marker of some sort, since I actually want to see it in the language,
I have to go with the first option.
The other argument against is that there isn't a sufficient benefit to
doing this. I'd argue that there is. Off the top of my head:
* Swizzling: given a 4D vector, there are 256 possible swizzling
operations. With dynamic dispatch, you can define them only as needed
without extra syntax.
* XML-RPC: Python has the best interface for this, hands down: just
connect to the service and go nuts.
* Message-passing: I had a big app a few years ago that was designed
around this. Everything went through a central messaging object.
Without this sort of syntax, I and everyone else would have gone mad
from continually writing `msgSink.sendMessage("blah")` everywhere when
`msgSink.blah` was perfectly unambiguous.
There ARE benefits to this sort of ability.
I don't think this would be something that you'd see everywhere; it'd be
relegated to a few specific types where it makes sense. Hell, you could
probably make Descent highlight such objects with a different colour so
you always know.
You CAN achieve a similar effect without special syntax. But you can do
foreach without foreach. And you don't need scope. Or classes. Or
symbols.
The two questions are: is it useful and is it worth the effort. The
first is definitely true from my experience, and I'm not sure we can
answer the second until we get some time with it to see how well it works.
Perhaps davidl could release his patch so it can be played with? :D
-- Daniel
