Glib::Value<T> oddities

[Dominique Würtz <dwuertz gmx net>]

My understanding is that Glib::Value (and GValue for that matter) is
something like boost::any, a container for values of arbitrary (well,
not really) type. Given this, the API to me loks awkward in so many
aspects, I thought I'd ask here about the reasoning behind some of the
design choices:

1. As the docs state clearly, I'm supposed to explicitly call the
init(GType) method to define the actual type of the value to be stored.

Glib::Value<int> x;
x.init(G_TYPE_INT);

Why isn't the call to init() already part of the constructor? The way it
is now seems totally unnecessary and error-prone to me. I do not see a
reason for init() to be exposed in the public API at all.

2. Closely related to 1., copy constructor and copy assignment of
Glib::Value<T> don't copy the GType. Again, I have to explicitly call
init() for the destination value??

3. Actually, looking at the relationship between Glib::ValueBase and the
various Glib::Value<T> subclasses it seems the sole role of
Glib::Value<T> is to provide an additional set(T x) method to set a
value. So I'm wondering whether this inheritance hierarchy is actually
needed at all? Why not just have a single (non-template) Glib::ValueBase
class (could be called just Glib::Value) with a set(T x) *method*
template? So essentially just like boost::any. Also, a Value(T x)
constructor and operator=(const T x) would be nice.

Dominique