Re: cluttermm: no effects?

[Daniel Elstner <daniel kitta googlemail com>]

Hi,

Am Dienstag, den 22.09.2009, 15:23 +0200 schrieb Krzesimir Nowak:
> > In Cluttermm animate is defined as:
> > Glib::RefPtr< Animation > animate (gulong mode, unsigned int duration,
> > const std::map< std::string, Glib::ValueBase > &properties)a

Eeek, it's a bad idea to have that in the API.  Glib::ValueBase and the
Glib::Value<> specializations are part of the internal infrastructure of
the C++ bindings.  It was never intended to be directly exposed in our
API.

To all C++ binding developers: Please do not create APIs which require
application developers to deal with Glib::Value<> or Glib::ValueBase
directly.  This is wrong.

The Glib::Value<> specializations exist in order to make it easy to
provide a decent C++-style interface on top of them.  What the C++ API
will look like depends entirely on the specific functionality that is to
be provided.  There is *no* generic way to wrap APIs using GValue.  Not
even the C API uses GValue as the primary interface for application
developers.

For an example of correct use of Glib::Value<>, see the metadata classes
Gtk::TreeModelColumn<> and Gtk::TreeModelColumnRecord in gtkmm, which
provide a statically type-safe C++ interface to the tree model data.
Another example is Gtk::Widget::get_style_property(), which allows
convenient access to the style properties by name, but without the
static type-safety guarantees provided by the Gtk::TreeModelColumn<>
API.  Neither of these substantially different design approaches expose
the Glib::Value<> and Glib::ValueBase types visibly in the public API.

The construction and initialization behavior of Glib::ValueBase and
Glib::Value<> is rather peculiar and intentionally follows the C API
closely.  It is not possible to use Glib::Value<> objects in a generic
manner like any other value type, particularly not as elements of STL
containers.

> Probably something like this:
> 
> std::map<std::string, Glib::ValueBase> props;
> std::pair<std::string, Glib::ValueBase> prop_pair;
> 
> // Glib::Value<float> inherits from Glib::ValueBase.
> Glib::Value<float> x, y;
> x.set(100);
> y.set(100);
> prop_pair.first = "x";
> prop_pair.second = x;
> props.insert(prop_pair);
> prop_pair.first = "y";
> prop_pair.second = y;
> props.insert(prop_pair);
> my_animation->animate(my_mode, my_duration, props);

It would look roughly like that if Glib::ValueBase had actually been
designed as public API.  The code will fail because the GValue is in an
invalid state until ValueBase::init() has been called.

Even if the example code would work as shown, it would still be a
horrible API.  It would be ridiculously verbose compared to the C
interface, but still without any type safety advantage!  You'd be better
off using the C API.

Let's try to avoid introducing something like a Variant type in the C++
bindings.  And Glib::Value<> is most definitely not that variant type.

Cheers,
--Daniel