[prev in list] [next in list] [prev in thread] [next in thread]
List: gtk-devel
Subject: Re: g_param_spec_pointer
From: Owen Taylor <otaylor () redhat ! com>
Date: 2001-12-18 21:28:37
[Download RAW message or body]
Tim Janik <timj@gtk.org> writes:
> On Tue, 18 Dec 2001, James Henstridge wrote:
>
> > I was just going through the GParamSpec code (I am implementing property
> > support for types defined in python), and noticed that there is no
> > standard param spec for types derived from G_TYPE_POINTER (created with
> > g_pointer_type_register_static(), such as GtkCTreeNode).
> >
> > Maybe g_param_spec_pointer() should be changed to take a "GType
> > pointer_type" argument. Unfortunately, this is an API change :( Any
> > ideas about this? It isn't so critical, because derived types still
> > work with the current param spec type.
>
> yeah, now that deriving from G_TYPE_POINTER actually presents some
> usefullness, i'd actually implement that function as:
>
> GParamSpec*
> g_param_spec_pointer (const gchar *name,
> const gchar *nick,
> const gchar *blurb,
> /* new argument: */ GType pointer_type,
> GParamFlags flags)
> {
> GParamSpecPointer *pspec;
>
> g_return_val_if_fail (g_type_is_a (pointer_type, G_TYPE_POINTER), NULL);
>
> pspec = g_param_spec_internal (G_TYPE_PARAM_POINTER,
> name,
> nick,
> blurb,
> flags);
> G_PARAM_SPEC (ospec)->value_type = pointer_type;
>
> return G_PARAM_SPEC (pspec);
> }
>
> note that you can still create a function like the above, e.g.
> named g_param_spec_typed_pointer(), since g_param_spec_internal()
> is an exported symbol. having that functionality in
> g_param_spec_pointer() would be better though.
> i don't actually expect much third party code to rely on
> g_param_spec_pointer() yet, so it might be worth persuing this API
> change on gnome-2-0-list, if you want to do that, you'd definitely
> have my support.
I think this change makes sense theoretically - but I don't think
it is compatible with the spirit of the API freeze. There are about
a dozen uses of it in GNOME CVS that would need to be fixed.
Plus, as Tim points out, we _can_ fix it compatibly now or later,
so an incompatible change isn't required.
Regards,
Owen
_______________________________________________
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic