Created attachment 279926 [details]
Test case

A patch by José Alburquerque has made it possible to make custom classes that
derive from interfaces with properties, such as
  class CustomAction : public Gio::Action, public Glib::Object

This is discussed in bug 697229 comments 13-16, 18-19, 21-25.
That patch is basically good and welcome, but some of my questions were never
really sorted out. I think some details could and should be improved.

I repeat here some of the questions I asked in bug 697229 comment 21, together
with new comments.

1. Would it be a good idea to add
   g_param_value_set_default(iface_props[p], g_value) in
   Interface::Interface(const Interface_Class& interface_class) and
   Class::custom_class_init_function(void* g_class, void* class_data)?

g_param_value_set_default() was added to the Interface constructor, but not
to Class::custom_class_init_function(). That's easily fixed.

3. The Class::properties_type vector that holds the values of the overridden
   properties of implemented interfaces is attached to the custom_type with
   g_type_set_qdata(). Those values are thus class data. They shall be instance
   data. Each instance of the custom class shall have its own set of property
   values.

The comments in bug 697229 indicate that José does not agree with me.
I claim that everything about a property (name, type, default value, etc.)
except its value is class data. But each instance of the class shall have its
own copy of the property's value.

I attach a test case that shows how a custom implementation of Gio::Action
(with read-only properties) and Gtk::Orientable (with a read-write property)
work.

4. Don't we need protected access methods to the overridden properties?
   Accesses through property_xxx() methods generated by _WRAP_PROPERTY are
   probably enough for read-write props, but what about read-only and write-
   only props? The class that implements the interface must be able to write
   a read-only prop, and read a write-only prop.

Comments in the test case show that this is more complicated than I thought
when I first made this comment. Perhaps a reasonable "solution" is that
a custom class that need read-only or write-only properties from an
implemented interface must provide set-methods for write-only props and
get-methods for read-only props, and private data members to store the values.