That's quite clever, but that is what I would classify as a 'trick' on the basis that if else elsif are designed conditional invocation of blocks of code.

The ternary is specifically designed for conditional assignment of values. Not many people baulk at using

my $min = ( $x < $min ) ? $x : $min;
[download]

. The only problem here is that there are two conditions instead of one, requiring the use of chained ternaries. But then, noone baulks at using nested or chained ifs, and the structure of the code is identical.

And is it really any clearer?

#! perl -slw
use strict;

for ( 1 .. 3 ) {
    print do{
        if( $_ == 1 ) { 'one' }
        elsif( $_ == 2 ) { 'two' }
        else{ 'three' }
    };

    print $_ == 1 ? 'one'
        : $_ == 2 ? 'two'
        : 'three';
}
[download]

To my eyes, the former is not even slightly clearer than the latter, but then I use this construct freely, when applicable and so I am used to seeing it and it presents me with no problems to read it. Especially if it is formatted well.

Indeed. The only reason why some of Perl's more obscure contructs are eshewed by some, is because they are obscure. It's a self-propogating argument. If more people used them, they would less obscure--more familiar--and the reason for not using them diminishes.

I'd go even further and say that using the appropriate operators for the operation has further benefits:

1. It prevents the confabulations of program logic.

   By this I mean that it forces a separation between different operations in a way that clarifies the code.

   Example: Given the code:

   my $var;
   if( <cond1> ) {
       $var =  <somevalue>;
   }
   elsif( <cond2> ) {
       $var = <someothervalue>;
   }
   else {
       $var = <default>;
   }
   [download]

   A spec change or bug fix results in this modification:

   my $var;
   if( <cond1> ) {
       $var =  <somevalue>;
       doSomething;
   }
   elsif( <cond2> ) {
       $var = <someothervalue>;
       doSomethingElse;
   }
   else {
       $var = <default>;
   }
   [download]

   I would much rather see that coded as:

   my $var = <cond1> ? <somevalue>
           : <cond2> ? <someothervalue>
           : <default>;
   
   doSomething     if $var == <somevalue>;
   doSomethingElse if $var == <someothervalue>;
   [download]

   To me, it much more clearly captures the semantics of the code.

2. It provides less opportunities for someone to come along and interperse code performing unrelated notions into the conditional blocks.
3. To a certain extent, even the fact that it may force later visitors to the code to actually read the code, rather than just scanning it, is itself a plus.

   I'm as guilty as the next man, perhaps more so, of scanning a piece of code and seeing what I think it does instead of what it actually does. If code that does conditional assignment to a variable, looks like an assignment to a variable (with conditions)

   my $var = ......;
   [download]

   , That is more likely to register as that than if it looks like a declaration of a variable followed by a set of conditional blocks of code:

   my $var;
   
   if( ...  ) {
       $var =  ...;
   }
   elseif( ... ) {
       $var = ...;
   }
   else {
      $var = ...;
   }
   [download]

   Where the primary purpose of the code is lost in it's construction.