Re: gperl_type_get_property() default on unichar prop

[Kevin Ryde <user42 zip com au>]

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
> gperl_value_from_sv()?

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;