Torsten Schoenfeld <[EMAIL PROTECTED]> 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.)
_______________________________________________
gtk-perl-list mailing list
[email protected]
http://mail.gnome.org/mailman/listinfo/gtk-perl-list
