Re: RFC: Operation Options API proposal

[Iago Toral Quiroga <itoral igalia com>]

El jue, 24-03-2011 a las 17:46 +0100, Guillaume Emont escribió:
(...)
> > Before starting, I think we need to ensure we agree on a few more points:
> >  - inherit from GrlData? (I'd say yes)
> 
> After some more consideration, I took the problem from a safer angle,
> and couldn't find many advantage of inheritance over composition in that
> case. Whereas I can see some advantages in using composition (in a
> private structure):
>  - application/plugin developers will know what API to use with GrlCaps
> (respectively GrlOperationOptions), and not hesitate with using the
> GrlData API
>  - for application/plugin developers that want some lower level stuff,
> we can add a generic grl_caps_get/set_value(), with its documentation
> stating that this is for people knowing what they are doing
>  - the use of GrlData becomes an implementation detail
> 
> The only advantage I could find to inheritance is that it would allow a
> slightly faster creation of objects, and a slightly lower memory
> footprint. But then, if these issues are critical, I guess we should use
> a plain GTYpe'd structure, and not a GObject.
> 
> So, how I'm starting the thing, is by having both GrlCaps and
> GrlOperationOptions inherit from GObject, with each a GrlData in their
> ->priv.

Ok, it is aligned with my suggestion in an e-mail I sent about 2 minutes
ago :), even thought I am skeptical about using GrlData here at all
(even for composition) for semantic reasons.

Iago