[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: fetching unset GParamSpec property



muppet wrote:

>> 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.
> 
> 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.

Looking at Kevin's recent test patch prompted me to think about this again.  I
now think that what you write above applies to SvFoo converters, but not to
newSVFoo.  SvFoo does SV*->Foo* in which case it is important that the result is
not NULL unless an _ornull variant was used, for the reasons you describe.  But
newSVFoo does Foo*->SV* and returning undef for NULL here is not a big problem.
 In fact, I'm unable to find any Foo*->SV* converter in Glib that chokes on
NULL.  Most simply return undef.

So I think newSVGParamSpec should do the same: return undef for NULL.  In that
case the change to gperl_sv_from_value can be reverted, and the various
Glib::ParamSpec constructors will also automatically start returning undef for
invalid input.

-- 
Bye,
-Torsten


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]