Re: GParamSpec further funcs



Kevin Ryde wrote:
I was having a nose around some of the Glib::ParamSpec bits and wondered
if g_param_value_set_default() could do the work for
$paramspec->get_default_value.  Or is there some magic in the current
dispatch?  I tried the couple of lines below which seem to work, though
bools may come out different from gperl_sv_from_value().

So what you're suggesting is that we implement a generic
Glib::ParamSpec->get_default_value by using g_param_value_set_default.
Good idea!  Currently, every subclass of Glib::ParamSpec implements its
own get_default_value.

+MODULE = Glib::ParamSpec     PACKAGE = Glib::ParamSpec       PREFIX = g_param_
+
+SV *
+g_param_xxx_get_default_value (GParamSpec * pspec)
+    [...]

It won't work like this though, I think.  The XSUB would need to be
called simply g_param_spec_get_default_value and would need to reside in
a MODULE section with "PREFIX = g_param_spec_".  Then you'd have to
remove all the get_default_value XSUBs from the various subclasses.
Since the subclasses inherit from Glib::ParamSpec, calling
get_default_value on them would now invoke your generic one.

If the test suite still passes after these changes, we have a winner.

I also wondered if there'd be some value in g_param_value_validate
and/or g_param_values_cmp.  I was tinkering with some comparing for my
"ConnectProperties".  g_param_values_cmp looks like it respects the
"epsilon" in float and double, though it also looks pretty useless on
boxed types (just a pointer compare).

Yeah, I think they would be useful.  Could you provide a patch with some
tests?

Also, your patch mixes spaces and tabs for indention.  Our convention is
to use four spaces for indenting the XS codewords (PREINIT, CODE, etc.)
and tabs for indenting code.

-- 
Bye,
-Torsten



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