develooper Front page | perl.perl5.porters | Postings from June 2003

Re: perlbool.pod rev.2

Thread Previous | Thread Next
From:
perl5-porters
Date:
June 30, 2003 05:31
Subject:
Re: perlbool.pod rev.2
Message ID:
bdpah0$44i$1@post.home.lunix
In article <D93B74F4-AAEE-11D7-9F5D-000393AE4244@dan.co.jp>,
	Dan Kogai <dankogai@dan.co.jp> writes:
> =head1 SYNOPSIS
> 
>    $f = "0";          # false by definition
>    $f = "";           # false by definition
>    $f = 0;            # false by definition
>    $f = 0.00;         # false because 0.00 == 0.
>    $t =  \$a;         # always true
>    $f = undef         # always false
>    $t = 1;            # true
>    $f = 10 - 10;      # equals 0 so false
>    $t = "0.00";       # true! see below
>    $f = "0.00" + 0    # numerically 0 so false
>    $t = "0 but true"; # true, though 0 in numeric conversion
>    @f = ();           # scalar @f is 0 so false
>    @t = (0);          # scalar @t is 1 so true!
>    %h = (0 => undef); # scalar %h is nonzero so %h is true
>    delete $h{0};      # scalar %h is now 0 so %h is false
> 
I think presenting the synopsis like this is actually pretty confusing, 
since it seems as if you are explaining the boolean value of the assign,
while you are really explaining what happens if you use the affected 
variable in a boolean context.

Which by the way DOES need a reference in this document. In particular
if (($a, $b) = ()) {...} needs mention.
(real use is of course: while (my ($key, $val) = each %hash) {...}).
There is also the case if (() = 1..3) {...}

But explaining bool in terms of variables is not the thing to do I think.
It also needs to have a meaning if no variables are in view, like:

sub foo {
    return 0, 1;
}

if (foo()) {....}

I think it's really better to explain a bool test is always in scalar 
context (so applied to a result scalar), explain the scalars that are 
true/false, and quickly review what several constructs mean in scalar 
context (so most of your synopsis would end up in the examples section 
of that).

> =item *

> All references are true since it is neither string nor number.
> This is unlike C which has null pointers.

Is that the reason ? I always thought it was because a reference in a
numeric (boolean) context is a number (the address it points to) and
the fact that this number is non-zero is what makes it true. In 
particular, if you fake a reference to 0x0, I'd expect it to be false 
actually.

> =head2 undef

> C<undef()> is always false because it would evaluate to C<""> in
> string context and C<0> in numerical context.

I prefer just saying undef is false and not trying to derive it
It's an axiom.

Thread Previous | Thread Next


nntp.perl.org: Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at ask@perl.org | Group listing | About