Fully dynamic d by opDotExp overloading

[Andrei Alexandrescu]

davidl wrote:
> 在 Sun, 19 Apr 2009 03:15:02 +0800，Daniel Keep 
> <daniel.keep.lists at gmail.com> 写道:
> 
>>
>>
>> Andrei Alexandrescu wrote:
>>> Michel Fortin wrote:
>>>> ...
>>>>
>>>> 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
>>
>> A related issue is that obj.opDotExp!"foo"(...) cannot be reflected over
>> because template instantiations aren't part of the typeinfo.
>>
>> Which means if you DO have any methods accessed via opDotExp, you CAN'T
>> invoke them dynamically at runtime, but you COULD if it took a string
>> argument instead of a string template argument.
>>
> 
> Umm, actually you can... but with bad duplication in code:
> 
> void Invoke(methodname, ...)
> {
>   if (methodname = "compile_time_dispatched_method")    // these sort of 
> comparison exists in template opDot in a static manner.
>   {
>     opDot("compile_time_dispatched_method")(args);
>   }
> }
> 
> Yes, we get duplication here. I don't have an idea to solve the 
> duplication elegantly yet. Maybe string mixins?
> 
>> Just sayin' :)

What you want is:

void opDot(string name, T...)(T args)
{
    invoke(name, variantArray(args));
}

void invoke(string name, Variant[] args)
{
    ...
}

So it's precisely the other way around. I agree you _could_ call things 
the other way, but it goes against the natural way.


Andrei