Beefy Boxes and Bandwidth Generously Provided by pair Networks
The stupid question is the question not asked
 
PerlMonks  

Re: Perl Idioms Explained - && and || "Short Circuit" operators

by decnartne (Beadle)
on Oct 24, 2003 at 15:20 UTC ( #301874=note: print w/ replies, xml ) Need Help??


in reply to Perl Idioms Explained - && and || "Short Circuit" operators

Pardon the perhaps obtuse questions, but

1.) why *exactly* is "It almost always considered better to use "or" instead of "||" when you work with open" and
2.) when considering  open( FH, "file" ) or die ... is there an error by including parens? in idiom? in style?

the asbestos suit is on, so flame away ;)

decnartne ~ entranced


Comment on Re: Perl Idioms Explained - && and || "Short Circuit" operators
Download Code
Re: Re: Perl Idioms Explained - && and || "Short Circuit" operators
by davido (Archbishop) on Oct 24, 2003 at 18:15 UTC
    I never intended to say there's something stylistically or idiomatically wrong with using parens with the open (or any other) function. perlstyle states that it is stylistically good to "Omit redundant punctuation as long as clarity doesn't suffer." But a few paragraphs later says, "...just because you CAN omit parenthesis in many places doesn't mean you should." But the example given is a situation with many levels of nested functions.

    perlop has this to say by way of introduction to "or":

    As more readable alternatives to && and || when used for control flow, Perl provides and and or operators (see below). The short-circuit behavior is identical. The precedence of "and" and "or" is much lower, however, so that you can safely use them after a list operator without the need for parentheses...

    Here is a key section of perlop:

    Binary "or" returns the logical disjunction of the two surrounding expressions. It's equivalent to || except for the very low precedence. This makes it useful for control flow:

    print FH $data  or   die "Can't write to FH: $!";

    This means that it short-circuits: i.e., the right expression is evaluated only if the left expression is false. Due to its precedence, you should probably avoid using this for assignment, only for control flow.

    $a = $b or $c; # bug: this is wrong ($a = $b) or $c; # really means this $a = $b || $c; # better written this way

    However, when it's a list-context assignment and you're trying to use "||" for control flow, you probably need "or" so that the assignment takes higher precedence.

    @info = stat($file) || die; # oops, scalar sense of stat! @info = stat($file) or die; # better, now @info gets its due

    Then again, you could always use parentheses.

    perlopentut says:

    If you prefer the low-punctuation version, you could write that this way:

        open INFO, "< datafile"  or die "can't open datafile: $!";

    perlfunc open recommends 'or' but then shows examples with both 'or' and '||'.

    My own reason for asserting it is amost always considered better is for several reasons: First, I can see the logic of it; it allows you to not worry about whether you have parenthesis in place. Second, it reads better; 'do this or that' makes for clearer reading than 'do this || that'. Third, after posting the original node, I received comments by several people reminding me that I should increase my emphasis on using 'or' in favor of '||' with open and in other flow-control places because it reduces the ambiguity of precedence. There is no question that "or" is going to be near the bottom of the precedence ladder, whereas "||" is quite a bit higher, and thus, one has to remember when constructing complex logical short-circuit operations which operators are going to bind more closely and which are going to bind less tightly.

    Perhaps "almost always" is too generous. But I do believe it is clearer, cleaner, less ambiguous, and less prone to context problems. 'or' probably shouldn't be used for "assignment" purposes (the examples above show this). But it seems to be a good choice for many logical flow needs.


    Dave


    "If I had my life to do over again, I'd be a plumber." -- Albert Einstein
      wow... thanks for such a thorough treatment of my questions in your reply and for the parent as well.

      decnartne ~ entranced

Log In?
Username:
Password:

What's my password?
Create A New User
Node Status?
node history
Node Type: note [id://301874]
help
Chatterbox?
and the web crawler heard nothing...

How do I use this? | Other CB clients
Other Users?
Others chanting in the Monastery: (8)
As of 2014-08-30 10:20 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?

    The best computer themed movie is:











    Results (292 votes), past polls