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



On 2014.06.06 20:18, Kjell Ahlstedt wrote:
If the glib developers decide to implement bug 698614, it's perhaps not
worth spending much time on a better Glib::Property class.


The glib bug 698614 has been recently fixed by reverting the original
fix. To my knowledge there are no longer any GLib issues that threat
Glib::Property.

I have attached preliminary patches to a new bug in the bugzilla:
https://bugzilla.gnome.org/show_bug.cgi?id=731484

I've tested the patches with complete applications that use
Glib::Property extensively and so far haven't seen any issues. Much more
testing is needed though.

The API/ABI stability can not be preserved completely from the
theoretical point of view unfortunately. I needed an additional data
member in the property object, so I sacrificed PropertyBase::param_spec_
pointer by replacing it with a pointer to a dinamically allocated pimpl
structure. While the param_spec_ pointer is not used by any inline
functions that we export, it can be accessed by users by deriving from
Glib::PropertyBase or Glib::Property.

Having said that, I believe that PropertyBase::param_spec_ is part of
glibmm private API and thus the meaning of the variable may be changed.
Even though users weren't formally forbidden to use the variable, it was
quite unambiguously marked private by the '_' suffix. Moreover, the
documentation says that properties can be used only as direct data
members of the containing type. While this requirement appears in the
documentation of Glib::Property, it's expressed as if it applies to
Glib::PropertyBase too (and, in fact, it does apply). This means that
the user is forbidden to derive from either type and thus param_spec_
can not be accessed without breaking the interface provided by glibmm.

If we agree that the param_spec_ variable is private, then the patches
do not break the API/ABI in the practical sense and thus are backwards
compatible while greatly enhancing the flexibility of Glib::Property.

Cheers,
Povilas



[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]