Re: dbus glib bindings: deriving from G_TYPE_BOXED, parameterized types

[Matthias Clasen <mclasen redhat com>]

On Fri, 2005-05-13 at 13:01 -0400, Colin Walters wrote:
> Hi,
> 
> It's rather timely that Owen mentioned the topic of deriving from
> G_TYPE_BOXED in the Cairo discussion.
> 
> I've been working on the GLib bindings for the D-BUS messaging system
> (http://www.freedesktop.org/Software/dbus).  The core problem I am
> running into is that D-BUS has a fully recursive type system which is
> difficult to map cleanly into GType (in its current form).  You can read
> about the D-BUS type system here:
> 
> http://dbus.freedesktop.org/doc/dbus-specification.html#message-protocol-signatures
> 
> Here is a copy of the DBus tutorial which I've patched to include a
> discussion of how my current patch to the D-BUS GLib bindings works:
> 
> http://web.verbum.org/files/dbus-tutorial.html#glib-client
> 
> The core approach that I've been taking now, as you can see from the
> above, is to map common D-BUS type signatures to some manually-defined
> GTypes, and punt the complex and weird ones into a special DBusGValue
> variant type.  This ends up *massively* simplifying the code, both the
> API and the internal marshalling/demarshalling.
> 
> However, hand-defining various types such as GArray<guint> is mildly
> painful; it's even worse for the GHashTable cartesian product.  Although
> I imagine for GHashTable not all of those will be in use; e.g. everyone
> seems to be using string keys only, and not using e.g. the *int64 as
> values.
> 
> Anyways though as you can see in the discussion of arrays in the
> tutorial, what I essentially want is twofold:
> 
> 1) A GType for GArray and GHashTable
> 2) "parameterized" subtypes of these
> 
> We need the parameterized types because the marshalling code needs to
> know what type an array contains in order to marshal, and the
> demarshalling code needs to verify that the demarshalled values match
> what a client was expecting.
> 
> I talked with Matthias very briefly about this, and he mentioned that he
> thought this issue hadn't come up before because in most normal APIs,
> when you pass down e.g. a GHashTable, the library expects that it maps
> e.g. string -> uint; it's only with remoting that one needs to
> manipulate values generically.
> 
> At first I was hand-defining a GType for each variant of
> GArray<subtype>, and I wrote a GType for
> GHashTable<gchararray,gchararray>.  However, I decided to try to make
> this more generic by defining a GType for GArray, and then deriving a
> "parameterized" subtype from it, using a generic function that looks
> like this:
> 

As I just pointed out to Colin, using derivation to model the relation
between generic types and their specializations is not really adaequate,
since you violate the substitution principle: a List<int> can not be
substituted for a List, since List promises you to store arbitrary
objectds, while List<int> can only store ints (which is why generic
types systems like the one in Java 5 don't do it like this).

We may need a different way to model the "is a specialization of this
generic type" relation.

Matthias