Re: Properties on interfaces

[Tim Janik <timj gtk org>]

On 18 Feb 2003, Owen Taylor wrote:

> So, if I understand correctly:
>
>  * You like the idea of properties on interfaces because:

hm? i was arguing in favour of interface property *implementations* in
instance implementations.

>    - GTK+ can check that the class is implementing
>      the properties it needs to implement.

yep, i'd like to provide automated checks if at all possible (i.e. wihout
breaking an otherwise clean and elegant design).

>    - Documentation and other introspection will work
>      correctly.

with only mild breakage/adoptions needed, yes.

>  * 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.

this is not restricted to nicks. the pspec API actually needs a TRANSLUCENT
flag and a function g_param_spec_get_original() that returns the original
(source) pspec for a translucent pspec. for nick and blurb, we'll want to
implement the convenient extension of looking up the values through the
original pspecs for translucent pspecs automatically.

> 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.

there's not a generic way to forward ranges and/or defaults and/or
stepping values (these are incrementation hints for pspecs used
in BEAST) or other assorted values because all pspecs implement
those in their own specific way. despite that, these are often
values you actually want to change if you override a parent class'
property implementation (at least the default is somewhat likely
to change).

> 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.

"Inherit" was the first thing i thought of, but it clashes with the
natural inheritance that pspecs are already using and that this
mechanism is not related to, so it shouldn't be called that way.
i'm not entirely happy with "translucent" either, "piggyback",
"forwarder", "shallow", etc. might be better and if you have
other suggestions you're welcome.

> (**) If a property is specified as CONSTRUCT in an interface,
>      is it allowed to be non-CONSTRUCT as implemented? If a

i think yes, this shouldn't be a problem.

>      property is specified as non-CONSTRUCT in an interface,
>      is it allowed to be CONSTRUCT as implemented? Same

i think not, because you should be able to query the interface for
the property types authoritatively, and CONSTRUCT would impose
a restriction on the property that is not reflected when querying
just the interface.

>      questions for CONSTRUCT_ONLY.

the reasoning above applies even more strictly here, the implamentations
idea of CONSTRUCT_ONLY simply has to match the interfaces idea, since
CONSTRUCT_ONLY determines exclusively *when* you may set such a property
(i.e. either *at* or *after* construction, but not both).
the same holds for G_PARAM_READABLE and G_PARAM_WRITABLE if that
isn't obvious.

>      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.

yes, if you mean to really exploit this circumstance, you could argue
that interfaces shouldn't care at all whether instance implementations
add an addition CONSTRUCT flag or not. i didn't argue along this line
in the above, because i like to think about construction properties
as something you'd conceptually determine and would e.g. always add to
an object creation dialog if you were to implement something like that.
that's a bit ignorant towards the fact that most people do determine
CONSTRUCT-ness of arguments due to implementation restrictions, but
at least i'm aware of that ;)

>      But CONSTRUCT_ONLY
>      makes an application-visible difference.

yep, right, thus the stricter reasoning.

---
ciaoTJ