Re: Overriding property defaults

[Tim Janik <timj gtk org>]

On 1 Apr 2001, Owen Taylor wrote:

> 
> Tim Janik <timj gtk org> writes:
> 
> > > The minimum to be able to do this without breaking source
> > > compatibility is adding _copy and _set_default functions to
> > > GParamSpecTypeInfo.
> > 
> > adding _set_default functions isn't sufficient, what if ranges
> > change in a child class, or G_PARAM_CONSTRUCT_ONLY suddnely
> > becomes a normal read/write property.
> > what if a child doesn't want to inherit a certain parent class
> > property because it takes care of its value internally?
> 
> The range of what is acceptable to do when overriding a parent
> property is _very_ small
> 
> The child can:
> 
>  - Change the default value
>  - Make the validator more restrictive
> 
> With the second being something you'd want to do only very occasionally.
> It is wrong, in my opinion for:
> 
>  - The child to make the validator less restrictive. (This would
>    break the parent widget.)

no it wouldn't, because the child has its own setter/getter, so it could
e.g. pass through those values that match the parent's range, and handle
other values differently.

>  - The child to override the setter/getter for the property
>    to do something else. (This probably breaks the parent widget.)

that happens always, automatically, a child installing its own
property (no matter whether its named the same as a parent property),
will have that prioperty be handled through its class functions.
from within there, it can just decide whether to chain to its
parent setter/getter by type prefixing the property name in a call to
g_object_set() (remember that type prefixing is deprecated for external
code since 1.2).


>  - The child to change the documentation. (Just wrong - the documentation
>    of a property can't be different in two places.)
> 
> Removing a property altogether is certainly highly dubious.

i don't think so, though i expect people to need that pretty seldomly,
specialization of a child class over a range of possibilities offered
by a parent class is a valid one:

typedef enum {
  LOOK_UNSPEC,
  LOOK_UGLY,
  LOOK_NICE
} LookType;

abstract class LookBase        { Property ("look", LookType, LOOK_UNSPEC, READWRITE); }
class TheUgly : LookBase       { Property ("look", LookType, LOOK_UGLY,   READABLE);  }
class TheNice : LookBase       { Property ("look", LookType, LOOK_NICE,   READABLE);  }
class TheChamaeleon : LookBase { Property ("look", LookType, LOOK_UNSPEC,   0);
                                 /* having this property doesn't make sense,
                                  * e.g. because we look partially ugly and
                                  * partially nice depending on further
                                  * object state
                                  */
                               }

> > so basically children need to be able to override parent properties
> > full scale, but that's best done with the g_param_spec_*() functions,
> > just the property lister needs to mask them out.
> 
> Can you be specific about what you are thinking of?

pretty much what we have right now (or, functionaly equivalent, had
in 1.2 already, module ranges), just that the property lister sorts
things accordingly (i.e. it shouldn't list you a property that is
neither readable nor writable).

> 
>                                         Owen
> 

---
ciaoTJ