libgdamm API: Values

[Murray Cumming <murrayc murrayc com>]

I thought I'd mention this in case anyone has ideas or strong opinions.

I'm porting the libgda C++ bindings to the latest version of the libgda
API. libgda is a database access API.

In libgda 1.2 they used a GdaValue struct which had functions such as
gda_value_get_string(), gda_value_get_boolean(), etc, which you could
use after identifying the type of data help by the GdaValue. It worked
OK.

In libgda 2 they have replaced that with GValue, which was a good idea. 


** Glib::Value is not for run-time type detection:

GValue is wrapped by Glib::ValueBase and its derived Glib::Value<>
specializations. So far, we don't use Glib::Value much, and when we do
it's as a variant whose actual type we examine at runtime. Instead, we
hard-code specific Glib::Value<> types in our applications and let the
compiler check that it is the correct type wherever possible.

Therefore, there's no C++ API for getting a bool, string, integer, or
whatever, from a Glib::ValueBase: There's no ValueBase::get_integer()
and ValueBase::get_string(). You must have an actual Glib::Value<bool>,
or whatever, and call get() on that.


** We need runtime type detection:

But a database access API is a bit different. There's no real way for
the compiler to know what types are really in the database, so the
application must be flexible at runtime. So I have used Glib::ValueBase
and added utility methods such as Gda::value_get_bool(valuebase) and
Gda::value_get_integer(valuebase).

That's ugly, of course. I could instead add get_*() methods to
Glib::ValueBase in glibmm itself, but that won't be enough because Gda
uses new underlying types (such as GdaBlob, ushort, etc) that glib and
glibmm doesn't know about. So then there'd be an ugly mix of member
get_*() methods and utility value_get_*() methods.


** How to do it:

So, I think the two choices are:
1. Use Glib::ValueBase plus value_get_*() utility methods.
2. Derive a Gda::Value class from Glib::ValueBase and add get_*()
methods.

The downside of 2 is that you will no longer be able to provide a
derived Glib::Value<bool> to libgdamm method instead of a general
Glib::ValueBase. When you really know the type, that's a nice convenient
type-safe API. And maybe there are other advantages to using the
existing Glib::Value<> system.

I have implemented 1 in cvs HEAD (gnomemm/libgdamm/), but I'm leaning
towards 2.


-- 
Murray Cumming
murrayc murrayc com
www.murrayc.com
www.openismus.com