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]