Re: [RFC] export TRUE and FALSE from someplace

[Bjarne Steinsbø <bosteins broadpark no>]

This discussion could easily turn into a religious war...  I don't 
really like to make any contribution towards that end, but anyway, here 
are my own two cents:

Firstly, if a value is to be chosen for FALSE, I feel that 'undef' is a 
better choice than '0' in perl.  Look at

 $a = (1 == 0);

Zero is also false, that is true, but a true boolean expression in perl 
returns undef or one, not zero or one.  (Sorry, I can't help it.  
Writing about boolean logic just makes it too easy to play on words... :-)

Secondly, I never liked TRUE and FALSE constants in the first place.  I 
think this is because I feel that they fall between two chairs.  They 
are unnecessary (don't improve readability) in code like

 if ($boolean == TRUE) { ...  } else { ... };

and I would argue they don't really improve readability that much in 
code like

 $widget->pack_start (FALSE, FALSE, 0);

In a module doing "pure" boolean logic, you could argue that TRUE and 
FALSE makes sense.  In most other cases you don't really have a generic 
boolean value, you have a variable that takes a "flip-flop" kind of 
value, i.e. it can either be on or off, true or false, or however you 
want to think about it.  And how you want to think about it varies from 
variable to variable.

If the booleans do have a more specific meaning, other names should be 
chosen (as Joe Smith demonstrated) with more semantic meaning:

 $box->pack_start ($widget, NO_EXPAND, NO_FILL, 0);

 $window->signal_connect (delete_event => sub { return 
STOP_EVENT_PROPAGATION });

Writing it this way takes you beyond expressing that "these arguments 
can either be on or off" to actually explaining what they do.  BTW, this 
is one of the places where I think Tk got it "right".  In Tk, the pack 
example would be
 $widget->pack (
   expand => 'no',
   fill => 'no',
   xpad => 0.0,
   ypad => 0.0,
 );
E.i. named parameters instead of positional ones makes for far better 
readability.  But that's a completely different discussion.

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.

> I get really irritated at reading gtk code with it's swamp of magic 
> constants.  Here's my 'constants' file:
>
> use constant 'True'   => 1;
> use constant 'False'  => 0; 

I would prefer (if TRUE/FALSE should be included at all)

 use constant TRUE => 1;
 use constant FALSE => undef;

It's a common idiom in perl to write constants in CAPITALS_WITH_UNDERSCORES.

> use constant 'Left'   => 0; 

 use constant LEFT => 0.0; # Emphasize that this is a float

Bjarne