in reply to Surprising result when using undef

I think I got too distracted by the way I was using undef inside if statement -- which is evaluating a variable or expression in boolean context -- and the fact that the expression is a test for numeric equality --

 if ( $possibly_undefined_val_here == 0 )

... because I've routinely used and understood something like  if ( $possibly_undefined_val_here ) to evaluate to "falsey" when the variable is undefined. I hadn't thought about it evaluating to 0, such that the resulting 0 == 0 in the boolean test becomes true, but of course it is.

But I also see that basically I got balled up in seeing that what I wanted was to have a flag that said "OK, we're in production mode because we have a truthy value, so let's roll" rather than one that said "OK, let's not roll if we're in development mode, so check to see whether we have a truthy value as to that, and, in order to be sure we remembered the issue, let's check to see whether we explicitly set the development mode flag to be the digit one or the digit 0."

I'm afraid this kind of complicated, inverted thinking gets in my way a lot. How elegant and direct is the logic of testing for the truth of a production mode flag, like testing to be sure a link in a chain is in place.

Really appreciate this information!

Replies are listed 'Best First'.
Re^2: Surprising result when using undef
by Marshall (Canon) on Feb 25, 2021 at 17:21 UTC
    I think that you have a good understanding!

    I'm not sure that it is 100% clear, but the // operator can be used like +=,*=, etc. I don't use any language other than Perl that has this operator. But this is a cool operator (added in Perl 5.10).

    In my coding, the most common occurrence would be something like $token //= ''; after some regex that might fail (and hence yield an undef). This means: if $token is defined leave it alone. However if it is undefined, set it to the null string. I do that right after the regex. This prevents warnings in comparisons and other ugliness with the DBI later on.

    In your code, perhaps: 

    $possibly_undefined_val_here //= 1;
if ( $possibly_undefined_val_here == 0 ){} #now always defined

    [download]
    However as I think you see now, it is much better not to intentionally generate any undef value on your own. The equivalent thing to //= in Perl <5.10 requires an if statement. Numerous studies show that an "if" statement is at least 10x more likely to contain an error - no matter how simple appearing the "if" statement might look. Your woes are a case in point.

    Update:
    Since your code is obviously intended to have different behavior in the production mode vs the debug mode. One feature of Perl that perhaps you should be aware of is the constant pragma.

    It is possible to write: 

    use constant DEBUG => 1;
if (DEBUG)
{}

    [download]
    If you change to: use constant DEBUG => 0; The if statements with DEBUG won't even be compiled! So there is no run-time penalty for code like that in the production version. By normal convention, constants are all CAPS although there is no language enforcement of that convention.
[reply]
[d/l]
[select]

In Section Seekers of Perl Wisdom