davidl wrote:
在 Sun, 19 Apr 2009 03:15:02 +0800，Daniel Keep
<daniel.keep.li...@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
