Re: Interfaces on properties, 2002-08-27
- From: Owen Taylor <otaylor redhat com>
- To: Tim Janik <timj gtk org>
- Cc: Gtk+ Developers <gtk-devel-list gnome org>
- Subject: Re: Interfaces on properties, 2002-08-27
- Date: Wed, 10 Sep 2003 18:31:52 -0400
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?
in CVS is the current version, that I believe applies fine against
> > - 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
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.
] [Thread Prev