Re^4: next unless condition

Replies are listed 'Best First'.
Re^5: next unless condition by dsheroh (Monsignor) on Apr 01, 2016 at 07:43 UTC
While I definitely agree that `or` doesn't clearly convey intent in this case, my understanding is that `or` was added as an alternative to `\|\|` primarily for flow control purposes in constructs such as `open my $file, '<', 'somefile.txt' or die;` where the high precedence of `\|\|` would cause unexpected issues. So I'd say that using `or` for flow control is completely appropriate in general, it's just not appropriate in this particular case. As for `unless`, I'm a big fan when it helps the code to read more like natural English. When you start getting into double negatives and complex expressions, then you swap it out for `if` because that's what happens in natural English.	[reply] [d/l] [select]
Re^6: next unless condition by RonW (Parson) on Apr 04, 2016 at 19:52 UTC
my understanding is that or was added as an alternative to \|\| primarily for flow control purposes in constructs such as open my $file, '<', 'somefile.txt' or die; where the high precedence of \|\| would cause unexpected issues. While the Perl documentation does mention flow control uses (and I am guilty of using it that way), not all programming languages guarantee the order in which terms are evaluated, or even short-cutting. In any case, `or` is named for a logic operation, not a flow control operation. So, would be better if we used `if` (or `unless`) instead of `or` for flow control. Update: Another thought: Just as `if` (and `unless`) can be used as a modifier, `else` could be used as a modifier. That would be clear indication of intent. Unfortunately, unlikely an `else` modifier would be added to Perl. The devs would likely say "Just use `or`"	[reply] [d/l] [select]
Re^7: next unless condition by afoken (Chancellor) on Apr 04, 2016 at 20:49 UTC
Just as if (and unless) can be used as a modifier, else could be used as a modifier. That would be clear indication of intent. Ahhh, the sweet smell of MUMPS: `OPEN 51:("foobar.txt":"W"):0 ELSE GOTO error` [download] (Note the significant white space) Or, slightly shorter: `O 51:("foobar.txt":"W"):0 E G error` [download] I can live with both, but `open ... or die` is shorter than `open ... else die`, and it's not that hard to understand. Alexander -- Today I will gladly share my knowledge and experience, for there are no sweeter words than "I told you so". ;-)	[reply] [d/l] [select]
Re^7: next unless condition by dsheroh (Monsignor) on Apr 05, 2016 at 08:37 UTC
not all programming languages guarantee the order in which terms are evaluated, or even short-cutting. Fortunately, we're talking about Perl here, not about "all programming languages", and Perl does guarantee a specific order of operations in which `\|\|` is very-high-precedence, `or` is very-low-precedence, and shortcut evaluation is the rule. I'm curious, though... Could you name a couple of languages in which the order of operations is not guaranteed? I don't think I've ever seen one myself and I have a hard time imagining the practical use of having an indeterminate order of operations. Just as if (and unless) can be used as a modifier, else could be used as a modifier. Not all programming languages allow the use of `if` or `unless` as statement modifiers, nor the use of `else` in that fashion. If using `or` for flow control is bad practice because it's not reliable in other languages, then surely the use of statement modifiers is just as bad. That would be clear indication of intent. As a native speaker of English, I find "open or die" to be a vastly clearer statement of intent than "open else die".	[reply] [d/l] [select]
Re^8: next unless condition by hippo (Archbishop) on Apr 05, 2016 at 09:09 UTC
Re^8: next unless condition by RonW (Parson) on Apr 05, 2016 at 18:37 UTC
Re^9: next unless condition by Athanasius (Archbishop) on Apr 06, 2016 at 07:57 UTC
Some notes below your chosen depth have not been shown here
Re^7: next unless condition by Anonymous Monk on Apr 04, 2016 at 20:20 UTC
In any case, or is named for a logic operation, not a flow control operation. So, would be better if we used if (or unless) instead of or for flow control. This is a weak argument, because for lots of things, the documentation was added to explain the behavior, not to explain what the designer envisioned. The http://perldoc.perl.org/perlop.html#Logical-or-and-Exclusive-Or explains or is useful for control flow purposes, thats as close to an endorsement as you can get, documented behavior that can be relied upon	[reply]
Re^5: next unless condition (if unless) by Anonymous Monk on Apr 01, 2016 at 08:34 UTC
In what way does it not convey intent? or is a boolean operator and implies an expression. Using if as a statement modifier is altogether different than forcing the role of implied if on the or operator. What? I don't understand what you're saying. The page you linked says `Binary "or" returns the logical disjunction of the two surrounding exp +ressions. It's equivalent to \|\| except for the very low precedence. T +his makes it useful for control flow: print FH $data or die "Can't write to FH: $!";` [download] So I don't see how intent isn't conveyed, `... or ...` is very common pattern, very familiar, seems like intent Completely replacing a chunk of code in order to make a small change to it means that the replaced code didn't scale at all! The "It" in "It also scales better" was referencing if compared to unless. Using unless tends quickly to get into double negative land making it harder to think about complicated expressions and harder to maintain code using them. Does it really matter what "It" you're refering? Ok, I'll give it a shot die unless $live; ## the original line, which I expand a minute later die unless $live or $reanimated; ## first change, and first error; mo +ving on for now die unless $live or $reanimated or !$cooked; ## second change double n +egative, scary, still error, abandon unless, abandon unless, abandon +unless die if !$live or !$reanimated or $cooked; ## clarity, it works ... but + some people think differently, so choice, die if !($live or $reanimated) or $cooked; ## whooops, error again, lo +gic not practiced die if !($live and $reanimated) or $cooked; ## works again, choice is +choice [download] So yeah, I don't see any issue with how it "scale" But I do see how having many things in unless gets confusing... if you cannot instantly write it correctly the first time because I don't practice using unless this way, I don't think about it that way but it didn't take a lot of practice to learn to use if, unless is the same way, just have to practice and learn but yeah most people don't do that	[reply] [d/l] [select]