Re: Properties on interfaces

[Owen Taylor <otaylor redhat com>]

So, if I understand correctly:

 * You like the idea of properties on interfaces because:

   - GTK+ can check that the class is implementing
     the properties it needs to implement. 
   - Documentation and other introspection will work
     correctly.

 * You think that the way to implement such a property
   is to simply install a property with the same name
   on the instance class.

 * To deal with the nick/blurb issue, you want to 
   introduce a TRANSLUCENT (*) flag which means 
   "if nick or name is NULL, look for a property
   of the same name on a parent class or interface"
   and get it from there.

Is that a good summary?

It sounds basically reasonable to me. I'm a little concerned
by the fact that the default and range need to be specified...
sounds like a good way to introduce subtle bugs, but 
it isn't the end of the world.

As for CONSTRUCT properties on interfaces, I was thinking
to disallow them, but if we go with the above scheme,
I don't really see any reason to disallow them, except
possibly that there are some questions about their exact
behavior which are hard to answer without a concrete
use case. (**)

                                      Owen

(*) I like Matthias's idea of INHERITED better for
    a name.

(**) If a property is specified as CONSTRUCT in an interface,
     is it allowed to be non-CONSTRUCT as implemented? If a 
     property is specified as non-CONSTRUCT in an interface, 
     is it allowed to be CONSTRUCT as implemented? Same
     questions for CONSTRUCT_ONLY. 

     A good argument for not-allowing CONSTRUCT parameters
     on interfaces is that since we don't require CONSTRUCT
     properties to be passed to g_object_new(), they 
     are basically implementation details. But CONSTRUCT_ONLY
     makes an application-visible difference.