Re: fetching unset GParamSpec property

[muppet <scott asofyet org>]

On Jul 13, 2008, at 11:35 AM, Torsten Schoenfeld wrote:

> Kevin Ryde wrote:
> > The program below gets some errors followed by a segv
> >
> >    GLib-GObject-CRITICAL **: g_param_spec_ref: assertion  
> > `G_IS_PARAM_SPEC (pspec)' failed at /home/gg/bug/default-value/ 
> > param-null.pl line 19.
> >    GLib-GObject-CRITICAL **: g_param_spec_sink: assertion  
> > `G_IS_PARAM_SPEC (pspec)' failed at /home/gg/bug/default-value/ 
> > param-null.pl line 19.
> >    GLib-GObject-CRITICAL **: g_param_spec_get_name: assertion  
> > `G_IS_PARAM_SPEC (pspec)' failed at /home/gg/bug/default-value/ 
> > param-null.pl line 19.
> >
> > I guess newSVGParamSpec() expect NULL.  Is it meant to?  Or is it  
> > up to
> > _gperl_sv_from_value_internal(), per below?
>
> I think newSVGParamSpec should follow the precedent of  
> gperl_new_object,
> gperl_new_boxed, and newSVGChar -- accept NULL and return undef.  As  
> in the
> attached patch.
>
> muppet?

I started to write "but that would render newSVGParamSpec_ornull()  
obsolete", but then i looked at gperl.h and there is no such symbol.

The original intent was for the newSVType() function to verify you  
actually had the type, and newSVType_ornull() to allow NULL, so that  
you didn't accidentally allow NULL everywhere and create warnings and  
assertions from the C code where you could have caught that with  
better type information in the bindings.  With that in mind, using an  
_ornull in gperl_sv_from_value() makes sense.  Well, actually, it  
kinda sucks, but that's our best hook into the property machinery, so  
that's how it happens.

But, as you point out, there are some heavy hitters that disobey this  
rule.  I'm at a loss for why.  :-(


--
Leia/Lois:  Aren't you a little fat for a stormtrooper?
Luke/Chris: Well, stay here and rot, you stuck-up bitch.
  -- Family Guy, "Blue Harvest" (A "Star Wars" parody)