Re: [RFC] export TRUE and FALSE from someplace

["muppet" <scott asofyet org>]

Bjarne Steinsbø said:
> E.i. named parameters instead of positional ones makes for far better
> readability.  But that's a completely different discussion.

this is very true.  however, to support this would be to rewrite the bindings
and the API completely.  you can look at it as "they're too lazy to redo it
all", "we gone too far to turn back", and "we're stuck with what gtk+ gives
us" with equal correctness.


> Joe Smith wrote:
>
> > Ok, I'll stick my neck out.  Hack away.
>
> There are some details that I would prefer different, but I support you
> 99% of the way.

as mentioned before, the fact that this is adding to gtk+'s API rather than
Perl-izing it means that it won't make it into the base bindings.  someone
else already pointed out also that you can use the nice names but still mess
it up by putting them in the wrong order, so i see such a proposal as going
too far without really improving anything.


my proposed list so far is for Glib *only*, and none exported by default:

  TRUE                    => 1
  FALSE                   => !TRUE
  G_PRIORITY_HIGH         => -100
  G_PRIORITY_DEFAULT      => 0
  G_PRIORITY_HIGH_IDLE    => 100
  G_PRIORITY_DEFAULT_IDLE => 200
  G_PRIORITY_LOW          => 300
  G_PARAM_READWRITE       => [qw/readable writable/]

rationale:  these are not defined as enums that can be treated through the
gtk2-perl automatically stringified constant mechanism.  the priority values,
in particular, would be problematic to use through the enum mechanism, as they
are merely discrete points in a continuous* space of priority values.


i leave the stock items as constants aside for the time being.


* relatively speaking.  they are still integers, so not truly continuous, but
that's a matter of pedantry which doesn't really change the meaning of my
statement.

-- 
muppet <scott at asofyet dot org>