Mr. Conway suggests that you can cascade uses of the ternary (?:) operator instead of an if-elsif-else chain. He feels this is much more readable. I strongly disagree.
I’m going to leave it to you to dig up a copy of the book and goo look at page 122, as I don’t feel like typing it all in here. I’ll just say that every time I run into this construct, I pretty much can’t read it at all and have to reformat it as if-elsif-else blocks to understand what the mess is doing. I find the ?: chain hides the control flow greatly, and mashes a whole bunch of details into a too-dense mess.
Perhaps this is just me, but I find this construct unreadable, uneditable, and unmaintainable. If you’re doing this, I think you’re doing something wrong.
For something that’s (in my opinion) far less readable and has the same performance characteristics, there’s no good reason not to use the more readable version.
Of course, Mr. Conway says exactly the same thing, just that the way I need to see it is the unreadable one.
Sure there are always different opinions. But at this one i can’t really understand why the tenary operator should be unreadable. It is basically the same, only with the exception that you have to type less with the tenary version. The idea is simple. Left is the condition, if the condition met, do the thing on the right side. Either way test the next condition. And this is exactly the same for if/elsif/else
if ( $name eq “foo” ) { }
elsif ( $name eq “bar” ) { }
elsif ( $name eq “baz” ) { }
else { }
and as a tenary version
$name eq “foo” ?
: $name eq “bar” ?
: $name eq “baz” ?
:
;
i can understand if people prefer the one or the other, but i can’t really understand why one should be not understandable. It is basically check the left thing, and if it matches do the right think. And formating it in a table “left/right”. You find that pattern nearly everywhere. In F#/Ocaml for example i would write:
match name with
| “foo” ->
| “bar” ->
| “baz” ->
| _ ->
The only think that really change are the symbols used to delimit the different cases. The structure even compares to a switch statements in other languages or given/when in Perl.
Nah, i really hate it when smaller/greater sign gets interrpetet as html without knowing it. Here are the code examples again. Hopefully complet:
if ( $name eq “foo” ) { |Do Something A| }
elsif ( $name eq “bar” ) { |Do Something B| }
elsif ( $name eq “baz” ) { |Do Something C| }
else { |Do Something D| }
$name eq “foo” ? |Do Something A|
: $name eq “bar” ? |Do Something B|
: $name eq “baz” ? |Do Something C|
: |Do Something D|
;
match name with
| “foo” -> |Do Somehting A|
| “bar” -> |Do Something B|
| “baz” -> |Do Something C|
| _ -> |Do Something D|
I fail to understand what’s so difficult to understand about a ternary cascade written in tabular form either. I use that extensively (and only just recently figured out a new trick to make it even better).
If I were working under a coding style that forbade this and forced me to write pyramid indents to use ternary cascades, I would give up ternaries almost entirely in favour of if-elsif chains with repeat assignments.
Funny, I had the opposite reaction. It was when I was reading PBP that I discovered ternary cascades written in tabular form, and I thought: “this is genius!”. You only have to put the effort into understanding it once, now everytime I see it, it’s second nature, and it’s so much more consice than the alternatives.