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;