I would change this line in your code:

$ret = &{$options{$opt}};
[download]

To this:

$ret = $options{$opt}->();
[download]

a) Is it worth using?

Definitely. It's a great way to handle a large number of options, IMHO.

b) Is this will be taken as a 'bad style' example?

It's a standard technique, so as long as you've got some comments explaining that it's a dispatch table it's fine.

c) Is if-elsif-elsif-elsif-else chain more efficient than this?

It might be, depending on how many options there are. Hash lookups are roughly constant-time operations, whereas a chain of if-elsif-else blocks would increase in time for every new condition added. Further, dividing separate tasks up into small subs is far better from a maintenance standpoint than a gigantic conditional structure.

Update: Expanded answer a bit.

Thanks friedo, I was lacking the name of such hash usage, maybe that's why I didn't manage to find nodes about it. Thanks again.

mulander,
Now that you know the name, perhaps Implementing Dispatch Tables may be of interest to you.

Cheers - L~R

There's another problem with if () elsif () elsif () ... else chains that bears mentioning.

It's an artifact of the way Perl source code is compiled down into the form used by the bytecode interpreter running underneath. The problem is that if any expression in any of the elsif conditions throws a warning (for instance, performing a comparison with a variable set to undef will emit an "Uninitialized variable" warning), then perl will report that the problem occurred on the line containing the if, not the actual line in question.

This is, as you can imagine, a royal pain when debugging if you're not aware of the quirk. In fact it causes a steady trickle of bug reports to be filed. The perl5-porters are currently evaluating how much extra memory it would take to save the additional line number information (that is currently being discarded) into the resulting bytecode in order to report the correct line number. So it may be fixed one day, but until then, dispatch tables are a good way of avoiding this gotcha.

• another intruder with the mooring in the heart of the Perl

It has already been mentioned that this is a known and useful technique. A way to improve it further in cases when you don’t actually need these functions elsewhere in the code is to put inline them in the hash assignment as anonymous functions:

my %options = (
    one => sub {
        print "one\n";
        return 1;
    },
    two => sub {
        print "two\n";
        return 1;
    },
    three => sub {
        print "three and break the loop\n";
        return 0;
    },
    '' => sub {
        print "Default\n";
    },
);
[download]

(I put the default into the hash under the empty string key; the choice of key is arbitrary, it’s just usually a good idea to keep everything together.)

Welcome to the world of first-class functions. :-)

Note also that references are always considered true, so instead of something like

if( exists $dispatch{ $action } ) {
     $dispatch{ $action }->();
}
else {
    $default->();
}
[download]

you can just say

&{ $dispatch{ $action } || $default }();
[download]

This lets you simplify your code:

while ( chomp( my $opt = <STDIN> ) ) {
    &{ $options{ $opt } || $options{ '' } }()
        or last;
}
[download]

Also, I notice in your code that you declared $ret outside the loop body. Unless you really need to use it outside the loop (which in your case, with the return code only being 0 or 1 and then only serving for control flow, you obviously don’t), it is good habit to declare it inside the loop instead. Keep variables scoped as tightly as at all possible.

Makeshifts last the longest.