Re: Proposal: make Glib::Property much more flexible

[Kjell Ahlstedt <kjell ahlstedt bredband net>]

A Glib::Property with less restrictions would be nice, if possible, 
especially if it's possible without breaking ABI or API.

There is a serious threat hanging over Glib::Property, described  in the 
bugs
https://bugzilla.gnome.org/show_bug.cgi?id=698614 (glib)
https://bugzilla.gnome.org/show_bug.cgi?id=721116 (gtkmm)

If the glib bug, preventing the installation of properties after 
class_init, is implemented, I don't understand how any custom properties 
can be added in a reasonable way in glibmm or gtkmm.

If the glib developers decide to implement bug 698614, it's perhaps not 
worth spending much time on a better Glib::Property class.

Kjell

2014-06-06 05:35, Povilas Kanapickas skrev:
> 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 sub-object 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 
> sub-objects 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