Re^3: next unless condition

Replies are listed 'Best First'.
Re^4: next unless condition by GrandFather (Saint) on Apr 01, 2016 at 06:03 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. In what way is it unclear? By not conveying intent. Using or in the role of an if does not convey the intent of the code so the code is unclear. How does it scale better? If you need to change the expression, why can't you change the entire line? 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. Premature optimization is the root of all job security	[reply] [d/l] [select]
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
Re^7: next unless condition by dsheroh (Monsignor) on Apr 05, 2016 at 08:37 UTC
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
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
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]