On 07/08/2010 09:28 AM, Shin Fujishiro wrote:
I too think that these features should be in Algebraic.
Excellent!
Actually, I created Any because Algebraic did not support dispatching
and copy constructing. I did not touch Algebraic because it was
rather difficult to implement opDispatch to the backing VariantN.
Then, may I integrate Any into Algebraic? The interface will be
changed:
Algebraic!(short, int) x;
x.allowed!int --> x.Algebraic.allowed!int
x.hasValue --> x.Algebraic.empty
x.peek!int --> &(x.Algebraic.instance!int())
Yes, absolutely. Your design is much better because it avoids hiding
e.g. "allowed" in some hosted type with its own "allowed". This will
become, I suspect, a gold standard for D types that define opDispatch or
alias this.
As you sure have noticed and as Michel pointed out, putting your stuff
into Algebraic might be a bit difficult. The design is simple, but the
implementation is quite hard to follow and relies on pointer to
implementation instead of index into implementation table. (Variant must
use pointer to implementation because it supports unbounded types.)
If you find it necessary to completely divorce the Variant
implementation from the Algebraic implementation, please do so.
Finally, a suggestion: I have hoped to find time to define opDispatch
for Variant. It should accept template variadics and dynamically
dispatch the call to the supported type if compatible, or throw an
exception otherwise. It's the dynamic counterpart of your opDispatch.
Example:
class A { double foo(int x) { return 1.0 / x; } }
auto v = Variant(new A);
Variant result = v.foo(2);
assert(result.Variant.get!double() == 0.5);
Internally, Variant would need to store a hashtable keyed by method name
with method information (parameter types, result type, pointer to invoker).
I think it's entirely possible to do that with what we have now, modulo
some small glitches in static reflection implementation. Once we have
that, we're really talking dynamic - like Python or Ruby dynamic.
P.S. I *love* the trick with the homonym inner namespace! It solves the
naming problem so elegantly. I'll use it in RefCounted too.
It was a bit surprising for me that the inner template could access
member variables without being mixed in. But I found that it's just
another "template member function", and so it's legal. :-)
BTW here's what I did in RefCounted:
struct RefCounted(T)
{
struct _RefCounted
{
... stuff ...
}
_RefCounted RefCounted;
... constructor, postblit, destructor, opAssign ...
}
Seems to work fine.
Andrei
_______________________________________________
phobos mailing list
[email protected]
http://lists.puremagic.com/mailman/listinfo/phobos
