On Tue, 05 Oct 2010 10:25:31 -0400, Don <[email protected]> wrote:
Steven Schveighoffer wrote:
One of the good goals of D I think is to be able to automatically
encapsulate a type, and all its attributes/functions, in order to
slightly alter the functionality. I think this is probably a pattern,
but I don't know what it is (Interceptor?).
One of the best methods to wrap a type is to use opDispatch. But
there are some problems that block this. It might be good to get a bug
report that gathers these together. I have one that I just ran into --
IFTI and literals. Basically, if you have a function:
void foo(short x);
you can call foo(1) no problem.
But if you *wrap* the type that contains foo, you cannot use
opDispatch to implement foo(1), because IFTI treats 1 as an int. So
what you get is an instantiation of opDispatch like this:
opDispatch!("foo", int)(1) Which then cannot call foo, because you
cannot cast int to short.
That is bug 4953.
I don't think so, because I'm using IFTI to imply the argument types. A
generic opDispatch to wrap a function:
auto opDispatch(string op, Args...)(Args args)
{
/* perform interception work here */
return mixin!("wrappedVal." ~ op ~ "(args)");
}
If you don't know what the arguments are *supposed* to be, I'm unsure how
to derive them based on what the type being wrapped supports.
The specific situation that's failing, in dcollections, I have a function:
add(V[] elems...)
where V is the type being collected. When V == short, then calling add
directly like this:
add(1,2,3,4,5);
works fine. But calling the wrapper with add(1,2,3,4,5) fails, because
Args... is interpreted as int, int, int, int, int.
What I really need is to say "hey IFTI, determine the argument types by
looking up as if it were called on this type, because that's what I'm
going to call" rather than use the arguments themselves.
Bug 4953 is when IFTI should play no part in determing the argument
types. Or am I missing something?
-Steve
