在 Sun, 19 Apr 2009 03:42:02 +0800，Michel Fortin
<[email protected]> 写道:
On 2009-04-18 11:19:38 -0400, Andrei Alexandrescu
<[email protected]> 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.
Umm, right, you hunt the problem I didn't consider before.
But in that case, actually you are trying to use a static info based
runtime reflection to deal with a dynamic D object. Just like you try to
deal with a dynamic object with previous introspection of it. I think for
runtime reflection against a dynamic object, the only way is querying the
object itself. And the object returns the runtime info back.
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.
--
使用 Opera 革命性的电子邮件客户程序: http://www.opera.com/mail/
