So, let's rough up an API design.

WARNING: Incoming wall of text.

The main problem we have is that shoving a bunch of property declarations inside G_DEFINE_TYPE_WITH_CODE is a bit messy. Additionally, that would make mixing classes with new style properties and classes with old style properties basically impossible. The last time I had to migrate GTK and GIO to the new instance private data it took a while, and it was a boring patch to review — and people still haven't finished porting their code now, 5 years and change later, judging from the amount of deprecation warnings coming from g_type_class_add_private() when building GNOME libraries and applications.

Ideally, 99% of the API should be hidden behind convenience macros, because boilerplate is boring.

Headers

Easy stuff:

The header stuff is pretty trivial, and are just declarations; it allows us to have a stable definition and naming scheme for setters and getters, and we could even end up parsing them from gobject-introspection.

Source

Buckle up, kids, because this is where it gets complicated.

First, we move the declaration of properties outside of class_init, in order to have a global variable with the property identifier:

This would expand to a C99 declaration:

Then, inside class_init:

Finally, accessors would be generated using the property offsets:

Side effects:

• this wouldn't work in non-C99 toolchains, and it wouldn't work in C++; we can ignore non-C99 toolchain, as we've bumped our compiler requirements, and C++ can use the underlying, non-macro API
• additional API that needs to live beside the old one for the next 10 years
• no need to change the allocation layout; properties are global to the type, and thus can be accessed directly
• the existing API would work, as we'd keep installing properties in the GParamSpecPool for backward compatibility, but we wouldn't access the properties through that mechanism any more, outside of g_object_set|get_property() and serialisation formats like GtkBuilder; per-property access would still be faster in those cases
• global declarations can only be constants, so this breaks type restriction on properties, like enums, flags, object, and boxed types; we could add the restriction later on, but it's kind of inconvenient
• the amount of global variables makes it even more unlikely we'll be able to support unloading types in the future, which means GTypeModule won't really be able to use this API

The last one is the problematic bit we were trying to avoid by storing the GProperty inside the class private data. I'm not entirely sure we still want to care, considering that you can't write plugins for anything that implements a GTK widget, as types are static anyway; but it's a thing, so we may want to still support it. The problem is that we cannot store all the properties inside the GObjectClass because each class may have its own overrides, and we cannot create a private class data structure implicitly because some types already have a private class data structure.

We could create the per-class storage when allocating the class data if we knew the number of properties when we register the type:

Of course, this prevents language bindings from using this API, because they do like doing things like adding properties post-class instantiation. It also makes the declaration a bit messy:

The property registration becomes:

This requires changing the layout of the memory allocation for GTypeClass, and adding a new field inside the node type to store the reserved space for properties, so we can use it when allocating the class.

Alternatively, if we wanted to have this inside the type definition, we could use:

Adding properties and generating accessors would follow the same mechanism as above.

The main side effect to this scheme is that we're now up to four different places where we declare or define properties. It would be much nicer if we could just memcpy() the property declarations inside the type node, and when instantiating a class create the GProperty instances ourselves; this would remove the need for adding properties inside the class_init altogether in the common case.

The major side effect is the re-implementation of finding and listing properties; we would have to write a new implementation that would:

• find_property:

  • check if the type class has properties added at type registration time
    • if it does, walk through the listed properties for the given name
      • if we find the given name, we return the GParamSpec we found
    • if it doesn't, we walk to the parent class, and repeat the check
  • if we don't find anything, we go through the GParamSpecPool for an old style property

• list_properties:

  • as above, but collect all properties instead of comparing and returning the first match

Implementing properties for interfaces is another messy thing; ideally, we want properties on interfaces to map to virtual functions on the interfaces themselves, but we cannot store the GProperty on the interface structure, unless we follow the same over-allocation scheme for GTypeInterface; we'd also need a bunch of different macros for generating the appropriate accessors and boilerplate.

Looking at interfaces, I think we don't really have to do anything for their properties.

g_object_interface_install_property add the pspec to the pool, and we call object_interface_check_properties in class_init, but thats about it. At runtime, the object property is used, which can be declared either the old-school way, or the new way.

Whats a little fuzzy in your api outline is GProperty vs GPropertyDecl - what gives ? Are they the same thing now?

The main problem with the initial GProperty implementation was that we had to access the GProperty out of the global pool, which slowed down the default C code path.

Whats a little fuzzy in your api outline is GProperty vs GPropertyDecl - what gives ? Are they the same thing now?

That's one of the options for the API: putting the property metadata in a structure that is statically allocated inside the source, so we can access it without having to access the GObject instance—which is, typically, the thing that requires locking.

The other option is to move the property metadata into the class private data, so we can access it as an offset, e.g.

Another option is to pull what the Rust bindings for GObject have done, have have a vfunc that returns the array of properties:

which would be equivalent to: