|
|
|
|
|
|
by ricardobeat
2753 days ago
|
|
|
Lots of other languages have postfix conditionals. On the readable boolean ops, all the Perl people recommend shying away from them except for a few specific constructs (do or die, eval or do, etc), since the weaker precedence rules make it really easy to shoot yourself on the foot: $a = $b or $c;
Where $a will never be assigned the value of $c. |
|
|
I didn't make a case as Perl being the only language, just that it's an interesting aspect of Perl. That said, I would be interested in what languages you are referring to. I haven't seen many.
> On the readable boolean ops, all the Perl people recommend shying away from them except for a few specific constructs (do or die, eval or do, etc), since the weaker precedence rules make it really easy to shoot yourself on the foot:
They are perfectly acceptable in a boolean statement. You only need to shy away from them when mixing them with assignments or higher precedence boolean constructs. The only case where you would have to worry is in non-simple boolean statements with assignment in the statement, or functions that omit parens for arguments in some cases, or mathematical operations without grouping parens, all of which I would argue should include their own grouping parenthesis for clarity anyway.
That said, I devoted space in both of my comments in this thread to noting that there are definitely places where you might shoot yourself in the foot with some of these features, and you'll note the examples I used them in are exactly as you've described, where they are either after a postconditional (in which case it's kept to a simple boolean statement which has no ambiguity), or to affect control flow (e.g. return or die), in which that assignment doesn't matter anyway.
> Where $a will never be assigned the value of $c.
Which I never used as an example for that reason, but that's the point of those operators. Being lower precedence allows for some alternate constructs than is possible in many other languages without them.
Someone asked for examples of constructs that help Perl match mental models of how might think of an algorithm, so I decided to explain a few. The purpose isn't to point out how Perl is better than Python or some other language, but how it's different in an interesting way. A lot of that was planned, but sometimes that came out to its benefit, and sometimes to its detriment. Like most interesting new things (because at the time it was), it's not entirely one thing or the other.