Fully dynamic d by opDotExp overloading

[Christopher Wright]

Michel Fortin wrote:
> The thing is that the name of that "catchAllHandlerFunc" function needs 
> to be standardised for it to work with runtime reflection.

I agree with this wholeheartedly.

However, opDotExp would be hamstringed if it were made to serve this 
function.

Since classes can implement interfaces, you could expose an interface 
IDispatch or the like. This doesn't suffice for structs, though.

> Let's look at the swizzle case. You want a class or a struct with a 
> function for every permutation of "xwyz". Beside doing that manually, 
> here's what you can do:
> 
> Solution A: use a mixin. This will add 256 functions to your struct, and 
> those functions will appear in the functionList used by 
> invokeViaReflection.
> 
> Solution B.1: use a templated catch-all function, and use the name to 
> instanciate the catch-all. Calling the function will work at compile 
> time, but at runtime invokeViaReflection is left in the dust.
> 
> Solution B.2: in addition to the templated catch-all function in B.1, 
> add a runtime catch-all. This is about twice the work, but 
> invokeViaReflection can work with those functions.

The standard form will be something like:
class Dispatch : IDispatch
{
    auto opDotExp(string name)(...) { return dispatch(name, _arguments, 
_argptr); }
    auto dispatch(string name, ...)
    {
       // do stuff
    }
}

This isn't much added work.

> Now, let's look at the proxy case, where you want to forward function 
> calls to another object. In fact, there are two variant of this case: 
> one where you know the type at compile-time, one where you don't (you 
> only know the base class) but still want to forward all calls.
> 
> Solution A: use a mixin. The mixin will create a wrapper function for 
> all functions in the wrapped object it can find using compile-time 
> reflection, and those functions will appear in the functionList used by 
> invokeViaReflection.

That's a lot of work, but it can get you a performance increase in the 
case where you know something about the class at compile time (for 
instance, you have an object that implements a particular interface, but 
you want to call non-interface functions via the wrapper).

Of course, you could manually forward methods as well and get the same 
performance increase. But that would be more difficult to write.

> Note that I'm not that much against a templated opDot, I just want to 
> point out its drawbacks for reflection. I'm also unconvinced of its 
> usefulness considering you can do the same things better using mixins 
> leaving only the runtime case to be solved, where you are better served 
> without a template anyway.

Well, you can do the same things with some other advantages with mixins, 
but it's harder to write.

I think the appropriate solution is to add a solver to the compiler that 
can determine valid inputs for opDotExp and, if that set is below a 
threshold, unroll the template into regular member functions.

Or, you know, just implement a static foreach that you can use in 
templates. And anything else that we can think of that's reasonable to 
make the mixin solution easier to work with.

If that's accomplished, there'd be no reason to have opDotExp as a template.