Fully dynamic d by opDotExp overloading

[davidl]

在 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' :)
>
>   -- Daniel



-- 
使用 Opera 革命性的电子邮件客户程序: http://www.opera.com/mail/