Re: GParamSpec further funcs

[Kevin Ryde <user42 zip com au>]

Torsten Schoenfeld <kaffeetisch gmx de> writes:
> +This is the C level C<value_set_default> method of GParamSpecClass.
> +If C<$pspec> doesn't have a C<default_value> field the return is
> +C<undef> (for example object or scalar).
> +
> +See also L<Glib::Param::Unichar> which has its own version of this method.
> +=cut
>
> I'm not sure the first sentence is useful to a Perl programmer.

Yep, though it's also one of only a few places the c and perl names
aren't the same.  Perhaps tone it down to just

    =for apidoc
    (This is the C level C<g_param_value_set_default> function.)
    =cut

(Since it's otherwise pretty self-explanatory.)

> Also, with
> the custom get_default_value xsubs gone from the subclasses, there will be no
> entry for it in their POD pages anymore.  It might be good to rectify this
> with a POD paragraph in every subclass:

I guess that's true of all subclasses though.

Perhaps just making the class hierarchy clearer would be enough.  I
didn't realize immediately the funcs like Glib::ParamSpec->double
created Glib::Param::Double etc.  And the pod for Glib::Param::Double
when you get there alas lacks a "HIERARCHY" section to enlighten the
ignorant that you can go back to Glib::ParamSpec for other methods.

Perhaps separate sections in the Glib::ParamSpec pod for
constructors-of-subclasses versus generic methods would help too.

(The subtly different Glib::Param::Foo versus Glib::ParamSpec names are
a bit off-putting too.  I guess for gtk3 there could be a chance to
switch to Glib::ParamSpec::Foo.  Not that names have to reflect
hierarchy of course, but "Param" starts to suggest the value instead of
the spec, if you know what I mean.)