Proposal to make Glib::Property much more flexible

[Povilas Kanapickas <povilas radix lt>]

Hello,

Currently Glib::Properties are limited by being required to be direct 
data members of the containing class object. Unfortunately, this makes 
impossible to use Glib::Property in most exported C++ APIs as additions 
or removals of Glib::Property members break the ABI. The issue could be 
solved by using the PIMPL idiom, but as of now this is not possible.

The direct data member requirement arises from the way property ids are 
used to map to property wrappers. At the moment we depend on the layout 
of objects of some type always having the same layout, which is 
guaranteed by the C++ standard. This allows us to define the property id 
as the offset of the property wrapper subobject from the start of the 
parent object.

I propose to depend on a different invariant that would greatly increase 
the flexibility of Glib::Property and would allow to use them as members 
of PIMPL structs. C++ standard guarantees that all subobjects of the 
given class are always initialized in the same order. We can employ this 
to define the property id as the number of already (re)installed 
properties during the construction of the current object. The addresses 
of the property wrappers could be stored in a separate, per object 
array. The property id could be used to retrieve the address of the 
property wrapper from that array.

We actually use this approach already for properties that are overridden 
by interfaces (see commit ce20003fd in glibmm). In this email I propose 
to use the same mechanics for non-overridden properties too.

This way the direct data member limitation would be lessened to only 
requiring the user to always construct the same number of properties in 
the same order, which wouldn't be an issue in almost all cases. In 
particular, the PIMPL idiom could be used for properties too.

If there's consensus among glibmm developers that this is a reasonable 
improvement, I volunteer to implement a patch and test it extensively.

All the best,
Povilas