Re: [boost] Thoughts on class "any"

From: Kevlin Henney (kevlin_at_[hidden])
Date: 2000-09-02 03:57:09

In message <B5D60D90.2E6%darylew_at_[hidden]>, Daryle Walker
<darylew_at_[hidden]> writes
>Neat class!  I wonder if something like this is how languages (usually minor
>ones) that have a "any"-like type do it?

It varies, but they often implement it in one of the following ways:

(1) An explicit union that is bounded in its possibilities, eg COM
VARIANT.

(2) The equivalent more elegantly expressed with a Handle/Body style, eg
Coplien's Envelope/Letter stuff and Peter Sommerlad's Anything class (I
think this was his EuroPLoP 98 paper)

(3) A tag discriminator, a void *, and a prayer, eg CORBA's any which
supports an unbounded set of types.

The External Polymorphism approach is far simpler, more elegant, and
less constrained.

>I have one major complaint: change the name of the "type_info" method!
>
>- I like the names of functions and methods to convey some sort of action.
>"type_info" sounds wimpy and/or too much like a noun.

I don't like this style at all: "get this", "set that" feels clunky and
low level. For queries I prefer the noun-based style found in much of
the standard library, eg size, width, capacity. For genuine actions, ie
non-const with side effect, a verb is justified because it is actually
doing something, eg erase, insert, swap.

>- The "type_info" name is already used (as a noun; a class name) in the std
>namespace, so it looks confusing.
>- The previous point is made worse by the fact that the "type_info" class is
>the return type of the "type_info" method!

OTOH, it could be argued that as a result of this you know exactly what
you're getting. That is why it is now the way it is. It used to be
called "type" in previous versions.

>A much better name would be something like "get_type."  

Definitely not ;-) Although, with hindsight I could be persuaded to
return to "type".

>(You could also go
>all the way and make it a conversion operator [to const std::type_info &],
>but I don't think "any" should be convertible to that class.)

That way lies darkness >:->

>- Why have multiple, consecutive "public" sections?  It looks like you are
>doing it to section your methods, but the comments alone will do it.

This is a style used to separate "method categories" more explicitly and
I've found it to work w/o problem. Sure, it's a matter of personal
taste, but I prefer this to comments that get lost.

>- You probably don't need all those access methods.  You can get rid of
>"copy_to" and "to_ptr" and make people live with "any_cast" and exceptions.
>The "any_cast" functions would have to be more "friend"-ly with "any" if you
>do get rid of the other access methods.  However, some compiler won't accept
>template friends and/or template methods, so you may need to work around
>those.

Aware of the problems. However, any_cast is too narrow an interface.

>- You could add a form of "any_cast" that allows a reference, especially
>non-const ones, to the held object.  

With a little bit of trait magic, this could be made to work
(<lament>why, oh, why can't we have partial specialization of function
templates?!</lament>). However, usual disclaimer: It won't work on
compilers not supporting partial specialization :-} Anyone else want to
see this feature? I think it makes it more like other values and cast
operators.

>Is there a way for "any_cast" to work
>if the destination type isn't the stored object's type, but the object can
>be converted to the destination type?

Not this model of a type: any is non-converting and intentionally so.

>- I never really liked the "operator const void *" hack to get around the
>over-eagerness of "operator bool" to be used in inappropriate integral
>conversions.  An alternate way around the problem would be to use "operator
>bool," and declare, but leave undefined, conversion operators for all the
>other integral types in a private section.  (This is similar to how
>"noncopyable" kills the copy constructor and assignment operator.)  Maybe I
>should add a class for this.

This is worth putting in if a problem is found with the operator const
void * "idiom" (;->).
____________________________________________________________

  Kevlin Henney                   phone:  [phone]
  Curbralan Ltd                   mobile: [phone]
  kevlin_at_[hidden]            fax:    [phone]
____________________________________________________________