I might do something like this:

my $func = ($foo > 7) ?
     $bar && \&bar_mysub
  || $baz && \&baz_mysub
  :  $bar && \&bar_other_mysub
  || $baz && \&baz_other_mysub;
$func->($foo) if $func;
[download]

Update: For the curious, here's what perltidy does with a longer version of the above (the above code puts makes perltidy put more on one line, so I added a bit more so it would get more broken up):

my $func = ( $foo > 7 )
  ? $bar && \&bar_mysub
  || $baz && \&baz_mysub
  || $bam && \&bam_mysub
  || $bak && \&bak_mysub
  : $bar && \&bar_other_mysub
  || $baz && \&baz_other_mysub
  || $bam && \&bam_other_mysub
  || $bak && \&bak_other_mysub;
$func->($foo) if $func;
[download]

I might do something like this:

my $func = ($foo > 7) ?
     $bar && \&bar_mysub
  || $baz && \&baz_mysub
  :  $bar && \&bar_other_mysub
  || $baz && \&baz_other_mysub;
$func->($foo) if $func;
[download]

Don't align things vertically for the sake of aligning them, align them so that they're readable! The fragment above borders on obfuscation. There's a mind-numbing repetitive pattern on the right, and this

  ||
  :
  ||
[download]

thing on the left. Yuch. I had to stop and really look at that fragment to get past the visual clutter.

Awwww man, i like that ... thing:

  ||
  :
  ||
[download]

gave me an Atari flashback! :D

I do commend runrig for giving a working piece of code that kicked the dog doo out of it's conterpart. It took me very little time to parse it, but i am not a newbie anymore.

For a newbie - that's just got to look like a nightmare. I really think that this is why Ovid loves nested if-else blocks:

Because newbies (especially those that are new to Perl but not to programming!) can understand them must faster.

Me, i like the dispatch table - once you really start using them, it's hard not to. Point of little return, so to speak. For one thing, it is very scalable - adding two new conditions was very easy:

my $func = ($foo > 7)
  ?  $bar && \&bar_mysub
  || $baz && \&baz_mysub
  || $qux && \&qux_mysub
  :  $bar && \&bar_other_mysub
  || $baz && \&baz_other_mysub
  || $qux && \&qux_other_mysub
;
$func->($foo) if $func;
[download]

I did move the '?' and the ';' to make it easier to cut-copy and paste it ... but, man have we gotten away from a simple solution:

Tuck the check for the value of $foo away in the subroutines themselves, redundant, but that should be a piece of cake to follow and seems more configurable in the long run as well as very straight foward. The redundant pieces will end up becoming different anyway, thanks to Murphy's Law. ;)

jeffa

  ||
  :
  ||
[download]

I would probably end up opting for:

$bar  && $foo > 6 ?  bar_func($foo) : other_bar_func();
$baz  && $foo > 6 ?  baz_func($foo) : other_baz_func();
$quux && $foo > 6 ? quux_func($foo) : other_quux_func();
[download]

UPDATE: Yes, I got the condition wrong (that's what I get for thinking in integers ;-). Quoth a maven, "it's a dispatch table without a hash!"

UPDATE2: Umm it seems the "?" walked off, they are back.

--
perl -pe "s/\b;([st])/'\1/mg"

Well, if you think using a goto is more readable than using another construct, then use it. I have seen code that were emulating goto's, and which were worse, much worse than the same code written with goto's.

I have read somewhere that there was Dijkstra's paper goto considered harmful, (http://www.acm.org/classics/oct95/) and then somebody answered with another paper "goto considered harmful" considered harmful. Unfortunately, I have not been able to find it.

Were you looking for Structured Programming with go to Statements by Knuth?

I don't see anything that improved on the nested if/else blocks so far. You have 6 cases so you are going to end up with six cases. You could factor out the common code like so:

{
    no strict 'refs';
    &{ ( $foo < 7 ? "" : "other_" )
     . ( $bar ? "bar" : $baz ? "baz" : $qux ? "qux" : last )
     . "_func" }( $foo );
}
[download]