Fully dynamic d by opDotExp overloading

[davidl]

在 Sun, 19 Apr 2009 03:42:02 +0800，Michel Fortin  
<michel.fortin at michelf.com> 写道:

> On 2009-04-18 11:19:38 -0400, Andrei Alexandrescu  
> <SeeWebsiteForEmail at 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.
>

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/