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

[Tim Janik <timj gtk org>]

On Fri, 13 May 2005, Colin Walters wrote:

> 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

is this type meant to be abstract (i.e. you'd only use boxed instances
which are truly parameterized)?

> 2) "parameterized" subtypes of these

> 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:
>
> dbus_g_type_get ("GArray<guint>")
> dbus_g_type_get ("GHashTable<string,gboolean>")
>
> There was really nothing D-BUS specific about this though.  It knew
> about GArray and GHashTable specially, and would register types for them
> which derived from G_TYPE_BOXED.
>
> It would then build a GType for the parameterized version, which derived
> from the GArray or GHashTable type.  However I ran into two problems:
>
> 1) Type names can't contain < or >

extending the charset for typenames s no problem. it's an arbitrary
limitation made inside gtype.c.

> 2) We can't "deep" derive from G_TYPE_BOXED

we didn't see a use for that until now. it can be switched on, the glib code
should just be checked for occourances of dependance on flat derivation of
boxed types. (i don't expect them to exist though)

> Now, I could give up on defining GTypes for these, but it has two major
> consequences:
[...]

> Anyways, what I am tempted to do for now is to continue to manually
> define GTypes for the common types in use not already defined in GLib
> (e.g. GArray<guchar> and GHashTable<string,string>).  Clients will have
> to access those types using the existing macros such as
> DBUS_G_TYPE_STR_STR_HASHTABLE and DBUS_G_TYPE_UINT_ARRAY.
>
> If GLib ever gets support for boxed subtypes and adding parameterization
> metadata to types, then I can change those macros to look like this:
>
> #define DBUS_G_TYPE_STR_STR_HASHTABLE (g_type_build_parameterized ("GHashTable<gchararray,gchararray>"))

could you outline what exactly you need besides tearing down the two
artifical limitations you described above? (e.g. present code for
g_type_build_parameterized(), etc.)

---
ciaoTJ