Skip to content
GitLab
Projects Groups Topics Snippets
  • /
  • Help
    • Help
    • Support
    • Community forum
    • Submit feedback
    • Contribute to GitLab
  • Register
  • Sign in
  • G GLib
  • Project information
    • Project information
    • Activity
    • Labels
    • Members
  • Repository
    • Repository
    • Files
    • Commits
    • Branches
    • Tags
    • Contributor statistics
    • Graph
    • Compare revisions
  • Issues 871
    • Issues 871
    • List
    • Boards
    • Service Desk
    • Milestones
  • Merge requests 41
    • Merge requests 41
  • CI/CD
    • CI/CD
    • Pipelines
    • Jobs
    • Artifacts
    • Schedules
  • Deployments
    • Deployments
    • Releases
  • Packages and registries
    • Packages and registries
    • Container Registry
    • Model experiments
  • Analytics
    • Analytics
    • Value stream
    • CI/CD
    • Repository
  • Wiki
    • Wiki
  • Snippets
    • Snippets
  • Activity
  • Graph
  • Create a new issue
  • Jobs
  • Commits
  • Issue Boards
Collapse sidebar
  • GNOMEGNOME
  • GLib
  • Issues
  • #2370

Strawman: Move GType down to libglib-2.0.so

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
Assignee
Assign to
Time tracking