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

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

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

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

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.)


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]