On 2009-04-18 11:19:38 -0400, Andrei Alexandrescu
<seewebsiteforem...@erdani.org> said:
I'm confused. Isn't it clear that at the moment we "have" the ability
to pass a function name as a runtime string?
Indeed, you can pass the template argument as a runtime argument to
another function. No misunderstanding here.
What we're lacking is the ability to implement that using reflection,
but that's an entirely separated discussion!
Runtime reflection lacking indeed, but wether runtime reflection is an
entirely separated discussion depends on if what we're doing will get
in the way of implementing it.
And no, you're not supposed to forward from invoke(string,
Variant[]...) to opDotExp - it's precisely the other way around!
Wrong. Whether it's one way or another entirely depends on what your goals are.
When writing in D and interacting with a scripting language, or remote
objects, you can write a function call that will use opDotExp to
forward the call to the script object. A template fulfill this goal
pretty well.
You may want the reverse too: call a D function from a script, or a
remote machine, via some runtime reflection mecanism. That's where we
have a problem: if the script calls function "foo", and the object
implements function "foo" using opDotExp (because the object is itself
a proxy to something else for instance), then it just won't work.
Also, if, for example, you use a templated opDotExp to implement a
bunch of related methods (like those "xyzw", "xwyz", etc.), then you're
making those inaccessible from reflection. If on the other hand you do
the same using a mixin adding true members to your class or struct,
then the compiler can include them in the reflection data, and they'll
be accessible to the outside world.
So, a runtime opDotExp is superior for some use cases because it works
for function calls comming from the outside (via runtime or
compile-time reflection), and you may need that if you want to expose
some D code via reflection.
--
Michel Fortin
michel.for...@michelf.com
http://michelf.com/
