Fully dynamic d by opDotExp overloading

[Don]

Michel Fortin wrote:
> 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.
> 
> 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.
> 
That's a very clear description.

Is the syntax sugar as important in that direction? I mean, this 
proposal doesn't make any difference other than to syntax sugar. You can 
already have
b = a.swizzle!("xwyz");
with the exact problems you mention. So it's not as if templated 
opDotExp creates new problems for function calls from the outside; it 
just doesn't solve the existing ones.

It seems pretty clear that dynamic programming languages and template 
value arguments don't get on well at all.