Fully dynamic d by opDotExp overloading

[Michel Fortin]

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.

-- 
Michel Fortin
michel.fortin at michelf.com
http://michelf.com/