Re: Custom container + Child type with interface

[Matthew Bucknall <matt mattbucknall com>]

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
>