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

From: Douglas Gregor (gregod_at_[hidden])
Date: 2002-07-01 21:11:10

On Monday 01 July 2002 09:06 pm, David Abrahams wrote:
> Oh, this is spooky. I am just implementing similar functionality in v2 of
> the Boost.Python library. In v1 it was called from_python.
>
> The problem: a Python object (usually managed via a PyObject*, but in
> Boost.Python managed with the wrapper class object) can in principle hold
> any C++ type. A major component of the Boost.Python library's functionality
> is the extraction of C++ objects from Python objects, and the wrapping of
> C++ objects into Python objects.
>
> So, should I call my from_python function variant_cast<> as well? I don't
> think that reads well. In particular, I think of a cast as generally being
> a peer-to-peer type transformation, whereas these "casts" are
> container-to-containee transformations. I was thinking of "extract":
>
>     extract<int>(obj)
>
> Now, "extract<>" might be too-general a name to use in namespace boost, but
> I'm not sure that it is. I do think it works better than "variant_cast<>".
>
> Thoughts?
> Dave

Very interesting. I'm most interested in the peer-to-peer vs. 
container-to-containee classification, because that really decides whether 
"extract" or "variant_cast" is the better name. 

How do we classify the relationship between a variant type and the value in 
that variant type? Is the variant type just a holder for another type, or is 
the variant type one of those other types, but with the decision made at 
compile-time? Thinking in object-oriented terms, is a variant like this:

  class Variant { /* ... */ };
  class IntegerValuedVariant : public Variant { /* ... */ };
  class FloatValuedVariant : public Variant { /* ... */ };

Or is a variant more like this:

  class VariantValue { /* ... */ };

  class Variant {
  public:
    VariantValue* value;  
    // ...
  };
  class IntegerValuedVariant : public VariantValue { /* ... */ };
  class FloatValuedVariant : public VariantValue { /* ... */ };

With the first view, a downcast from a Variant to one of the values it may be 
is a peer-to-peer transformation, so if we think of a variant like this then 
I believe variant_cast is the right name.

With the second view, a variant is a container-of-one. The name "extract" 
makes perfect sense here, because it is accessing the only value in the 
container. 

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. 

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). 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?

        Doug