GitLab

The type system is not a huge amount of code, and there's no real need why it should live in libgobject, when a good chunk of types exposed by GLib are boxed in there.

In practical terms, the type system is just a low level API not dissimilar from GVariant. My proposal is to literally move the existing GType and GValue API down one level, with no ABI/API changes; this would allow us to use the type system for the GLib data types out of the box, as well as adding type specialisation to the opaque data containers. We could even add API to GArray/GPtrArray to properly store typed data, and finally replace GValueArray.

The main objection from existing consumers of GLib is that GObject strings along a bunch of additional functionality—signals and properties, closures, etc. We can easily keep those into libgobject-2.0.so; I'd actually insist in keeping them isolated in libgobject, in case we decide to create a new base object class that does not have the known issues of GObject.

The complexity of this surgery is mostly limited to:

• moving existing GObject/GClosure/GParamSpec initialisers to their own file from gtype-private.h and gtype.c
• moving gtype.[ch] and gvalue.[ch] and ancillary private files from gobject to glib
• ensuring that the type system is initialised alongside GLib
• ensuring that the GObject ancillary types are initialised