[Date Prev][Date Next] [Thread Prev][Thread Next]
[Thread Index]
[Date Index]
[Author Index]
Re: fetching unset GParamSpec property
- From: Torsten Schoenfeld <kaffeetisch gmx de>
- To: gtk-perl-list gnome org
- Subject: Re: fetching unset GParamSpec property
- Date: Sat, 23 Aug 2008 17:02:42 +0200
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]