Re: gperl_type_get_property() default on unichar prop

Torsten Schoenfeld <kaffeetisch gmx de> writes:

I don't know.  The current get_default_property_value() certainly
allows custom param specs to provide their own get_default_value() and
have it called when appropriate.

I wondered after if that works, if a subclass would have to identify
itself to the GType registration and/or gperl_register_param_spec()
before the method dispatch etc would go to the right place.

The only possible solution that comes to mind is to attack this at the
only place that sees both the GParamSpec and the GValue:
get_default_property_value().  Maybe it could, upon a seeing a param
spec of type G_TYPE_PARAM_UNICHAR, mangle the SV returned by
Glib::Param::Unichar::get_default_value() before passing it to

I guess so.  The comments could note g_param_value_set_default() though,
perhaps per below, if the wording isn't too provocative ...

Index: GType.xs
--- GType.xs    (revision 1054)
+++ GType.xs    (working copy)
@@ -1545,21 +1545,23 @@
                             GParamSpec * pspec)
-        * not all pspec types support a default value, and user code can
-        * add pspec types; thus, glib does not provide a unified way to
-        * get a default value for a param.  also, the default value member
-        * may be at different offsets in the various param spec structs,
-        * so to do this in pure C we'd have to create a whole slew of
-        * helper functions to set the default values and put them in a
-        * hash table (or an if-else tree -- since the type codes are dynamic,
-        * we can't use them in a switch).  however, that would leave us with
-        * code bloat and a maintenance problem, since we'd have to add code
-        * for each new param type, and we'd never handle custom params.
+        * g_param_value_set_default() is the unified way to get the default
+        * value from a pspec, when it has one.  Using that would be smaller
+        * and faster and have the advantage of hitting the
+        * value_set_default() vfunc in new pspec classes defined in C.
-        * instead, let's use the existing infrastructure in the bindings,
-        * and let perl's oo system do the hard work for us.  this will catch
-        * any custom params as well (provided their default_value accessors
-        * have been bound), at a slight cost in performance.
+        * But it would have the disadvantage of missing a perl subclass
+        * get_default_value() method [does such a thing work? does it need
+        * an explicit subtype registration?]  Of course other C code using
+        * g_param_value_set_default() also misses a perl
+        * get_default_value() method until there's a vfunc tie-in to set
+        * that up.
+        * 
+        * FIXME: for g_param_spec_unichar(), ie. G_TYPE_PARAM_UNICHAR, the
+        * Glib::Param::Unichar::get_default_value() method returns a
+        * single-char string, whereas the G_PARAM_SPEC_VALUE_TYPE() of such
+        * a param is G_TYPE_UINT, leading to a warning and wrong result in
+        * gperl_value_from_sv() called here.
        const char * package;
        GV * method = NULL;

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