Re: [boost] Re: Re: Yet another Variant class

From: David Abrahams (david.abrahams_at_[hidden])
Date: 2002-07-02 03:35:24

From: "Douglas Gregor" <gregod_at_[hidden]>

> I personally favor the first view, and therefore the name variant_cast.
With
> the variant type we're describing (I'll get to PyObject* in a moment...),
I
> think of the favorite expression example:
>
>   class Plus;
>   class Minus;
>   typedef variant<Plus, Minus, double> expression;
>
> Does the 'expression' type contain an expression or is it an expression?
OO
> textbooks would tell us to write the object hierarchy like this:
>
>   class Expression { /* ... */ };
>   class Plus : public Expression { /* ... */ };
>   class Minus : public Expression { /* ... */ };
>   class Literal : public Expression { /* ... */ };
>
> Why? Because Plus is-a(n) Expression, and a Literal is-a(n) Expression.

'xcept it ain't. There is no is-a relationship with variant. If there was,
I'd be able to pass a double* where an expression* was expected.
Structurally speaking you've got it inside-out, in fact. Given an
expression lvalue, we can get a double lvalue.

> With PyObject*, I think it is the same question. A PyObject* is a just a
> placeholder for a type we can't determine statically (like 'Expression'
in
> the hierarchy above).

Well, it might be multiple types. Probably is, in fact.

> When we know the type dynamically, we cast to that
> type, just like we would dynamic_cast in the OO style.
>
> PyObject*, variant, any -- they're all just union types. Is a union a
> container of one?

Yes! A union definitely does *not* present a logical is-a relationship.

-Dave