Fully dynamic d by opDotExp overloading

[Andrei Alexandrescu]

Michel Fortin wrote:
> On 2009-04-18 03:23:21 -0400, Andrei Alexandrescu 
> <SeeWebsiteForEmail at erdani.org> said:
> 
>> If you want to invoke a method known as a string variable, opDot or 
>> whatever has nothing to do with it. You don't need any change to the 
>> language at all, because you'd write:
>>
>> string foo = "bar";
>> d.call(foo); // call method bar
>>
>> What opDot does is to allow the regular member syntax while still 
>> allowing the callee to look up the name statically or dynamically 
>> (assuming the method name is passed into opDot as a template 
>> parameter).   Note, again, that opDot has everything to do with the 
>> syntax and next to nothing to do with the semantics, which is 
>> realizable without any change in the language. And that's how the 
>> cookie crumbles. I understand you don't like that, but at least we 
>> should be clear on where the feature starts and where it ends.
> 
> Andrei, I think you, and perhaps everyone here, are overlooking one 
> small but important detail.
> 
> opDotExp, if a template like you're adovcating, undermines future 
> runtime dynamic call capabilities (which are part of most runtime 
> reflection systems).
> 
> If you're going to have something such as
> 
>     d.invoke("foo");
> 
> available on any type (using some yet-to-see runtime reflection), it 
> will work for a non-template opDotExp (invoke would just forward to 
> opDotExp with the string "foo" if it doesn't find the member through 
> reflection), but it cannot work for an opDotExp template using "foo" as 
> a template argument since string "foo" is a runtime argument. (In fact, 
> I don't see how any template can be callable from runtime reflection.)
> 
> It ensues that if later we add runtime reflection to D, dynamic calls 
> won't work for template opDotExp.
> 
> So I'm not really convinced that template is the way to go, even though 
> it would allow great things. Almost all you can do with a template, you 
> already can do by adding members using a mixin. And adding members using 
> a mixin will also work with runtime reflection, unlike templated 
> opDotExp. The only use case left unadressed by mixins and runtime 
> opDotExp is the function with an infinite number of members which want 
> compile time dispatching.
> 
> Perhaps we need both template and runtime opDotExp...
> 
> Anyway, I like the general concept so I hope we'll get it, template or 
> not. I just feel the point above has been neglected in the discussion.

I'm confused. Isn't it clear that at the moment we "have" the ability to 
pass a function name as a runtime string? What we're lacking is the 
ability to implement that using reflection, but that's an entirely 
separated discussion!

And no, you're not supposed to forward from invoke(string, Variant[]...) 
to opDotExp - it's precisely the other way around! I'm not sure where 
I'm wrong in explaining this, it looks like I'm unable to remove a very 
persisting confusion.

So let me restate: opDotExp taking a runtime string does not EXPAND your 
options, it severely LIMITS them. It's very simple: with the former you 
have strictly LESS options and no NOTHING in terms of added power. It's 
simple, I swear.


Andrei