Re: g_param_spec_pointer

[Owen Taylor <otaylor redhat com>]

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