I agree entirely. The problem has arisen because of what I consider a flaw in the way GObject uses properties during construction (via g_object_new() etc). Seems to me, it should be perfectly acceptable to define a property that can be set at construction, but then only read during the rest of the owning object's lifetime (i.e. something like G_PARAM_READABLE | PARAM_CONSTRUCT_ONLY), but GObject does not allow this - at least, it didn't work when I tried. In my opinion, an object cannot be considered to fulfil 'is-a anything' until it has been fully constructed, so the 'is-a' pattern mandated by an interface during the construction phase is, for the most part, irrelevant. I suspect, I'll have to change the interface in question to use methods rather than properties. But that does feel like a compromise I should not need to make - especially as I'll have to get around loosing property change signals I would have otherwise used. Thanks, Matt. On Sun, 2009-12-20 at 19:22 +0100, David Nečas wrote: > On Sun, Dec 20, 2009 at 04:43:57PM +0000, Matthew Bucknall wrote: > > Next question - The interface I have defined basically just mandates a > > few properties. The container that requires children to implement this > > interface only ever reads these properties. > > > > Some implementers of the interface will determine the value of the > > interface properties based on various bits of internal state > > information. Other implementers will be passed the property values via > > their constructors. > > > > So as far as the container and some implementers are concerned, the > > interface properties only need to be G_PARAM_READABLE. In other cases, > > the properties might need to be (G_PARAM_READWRITE | > > G_PARAM_CONSTRUCT_ONLY). > > > > I assume that the interface definition has to go with the lowest common > > denominator, which I think is G_PARAM_READWRITE. In that case, what > > should implementers do where the properties are not settable (because > > they are derived from other state information)? > > I've never had to override properties (fortunately), so just some OO > theory... > > You do not go with `the least common denominator'. The is-a relation > between subclases and classes or implementations of interfaces means that > you can always say MyFoo is a GpanePanel if it implements the interface. > In other words, you must be always able to substitute the derived object > for the parent. > > You can't do this if the parent has writable properties but the child > has not. > > So to mandate the is-a relation in case of your properties, the parent > must have the most *restrictive* flags (typically G_PARAM_READABLE). > Subclasses can then permit more operations. > > Regards, > > Yeti > _______________________________________________ gtk-list mailing list gtk-list@xxxxxxxxx http://mail.gnome.org/mailman/listinfo/gtk-list
