Re: Interfaces on properties, 2002-08-27

[Owen Taylor <otaylor redhat com>]

On Wed, 2003-09-10 at 17:51, Tim Janik wrote:
> On Wed, 27 Aug 2003, Owen Taylor wrote:
> 
> > Here's another version of interfaces on properties, modified
> > to more closely follow what you sketched out in:
> >
> > http://mail.gnome.org/archives/gtk-devel-list/2003-July/msg00162.html
> 
> 
> there were some confusing parts in the diff, i.e. it looked like you
> diffed it against another patched gobject version. can you resend it
> in a version that applies cleanly against CVS and contains only the
> parts you claim, please?

 gtkfilechooser/glib-interface-properties-0.5.patch

in CVS is the current version, that I believe applies fine against
CVS gobject.

> >  - The main open question in my mind is whether we should keep
> >    g_param_spec_set_redirect_target() and the REDIRECT flag as
> >    a separate concept from g_param_spec_override() - if we
> >    simply made g_param_spec_get_redirect_target know about
> >    G_PARAM_SPEC_OVERRIDE, we could get rid of the need to
> >    store the redirect target in qdata.
> >
> >    Right now, you can do a couple of things with
> >    g_param_spec_set_redirect_target() you can't do with
> >    a hidden g_param_spec_override():
> >
> >     - You can have your own implementations of set_default(),
> >       validate() that don't just chain up.  '
> >     - You can set nick/blurb on your paramspec and have
> >       that override the nick/blurb from the redirect target.
> >
> >    However, since redirected properties are invisible to
> >    g_object_class_list_properties() and
> >    g_object_class_find_property(), I'm not sure that's a good
> >    thing to allow.
> 
> i don't think that's a good idea either, as mentioned in previous mails.

What do you think, then, of making g_param_spec_set_redirect_target()
not public? What about making g_param_spec_get_redirect_target()
just expect a GParamSpecOverride rather than using qdata?

> >  - g_object_class_check_iface_properties() needs to be reworked
> >    once we have a g_type_set_interface_postinit_function().
> 
> can you outline how you imagine interface_postinit to look like?

What I'd have imagined a function that gets called immediately after
the iface_init function gets called for any interface on any type
deriving from the specified type.

> in particular, i'm thinking along the lines of a more generic than
> specific version, to avoid adding more and more class hooks in
> the future. e.g. i'd prefer a simple callback that just gets the
> class type and is called everytime the class finished initialization
> and when interfaces are aded thereafter.
> however, that'd mean the callback doesn't have any information about
> what interfaces got newly added and will always have to check the
> full set.

Hmm, that's going to be significantly more work (the checks aren't
particularly cheap)

My instinct would be to, if we have exactly one purpose in mind
for such a post-init-check, to make it handle that one case and
handle it well.

Regards,
					Owen