Have a look at Implementing Dispatch Tables in the tutorials section.

{   # start a new scope to keep the effect of "no strict" small
    no strict 'refs';
    $return_value = &$generic_sub(@args);
}
[download]

Another involves eval:

$return_value = eval("$generic_sub(\@args)");
die $@ if $@;
[download]

use strict;
use warnings;

my $meth_name = 'foo';
__PACKAGE__->$meth_name('camel');
exit( 0 );

sub foo {
    my ($self, $arg) = @_;
    print "$arg (on behalf of $self)\n";
}
[download]

which prints

camel (on behalf of main)
[download]

I definitely prefer the “dispatch table” idea, because this gives you the very-important ability to know what the actual possibilities are. And, most importantly, to do something intelligent if what you've actually read from your input file is, for whatever reason, “none of the above.” (Hey, 'ka-ka occurs!' and your programs must be ready for that.)

The idea here, as stated elsewhere, is that you create a hash containing all the possible key-values and a reference to the subroutine that is to handle each one. (Be sure to check for 'undef' ... which will occur if the input-value isn't in the table.) This trivializes the inevitable case where two-or-more inputs need to be handled by the same routine. Perhaps the greatest benefit of all is that it very-clearly documents what inputs this program will accept and what it will do with each one.

use strict;

sub dynamic {
  print "Mmm, dynamic.\n";
}

my $name   = 'dynamic';
my $subref = \&$name;
&$subref();
[download]

I find this very surprising. But I checked it and it apparently works.

Why does this give an error:

use strict;
sub dynamic { print "hello\n"; }

my $name = "dynamic";
&$name();
[download]

.. and yet this is ok? (they differ only in the last line)

use strict;
sub dynamic { print "hello\n"; }

my $name = "dynamic";
&{ \&$name }();
[download]

Before seeing this, I would have bet anything that the &{\&{ ... }} operation was absolutely the same as &{...} (barring weird action-at-a-distance caused by tying, overloading, etc). In fact, I'm not sure whether to consider this a bug or not. Indeed, what is \&$name doing other than "using string as a subroutine ref", which is outlawed under strict refs?

Yet a similar idea with other kinds of refs doesn't do this. Both of these examples fail under strict refs (in my mind because @{\@{...}} is unconditionally the same thing as @{...} ):

use strict;
our @dynamic = ("hello\n");

my $name = "dynamic";
print @$name;
[download]

use strict;
our @dynamic = ("hello\n");

my $name = "dynamic";
print @{ \@$name };
[download]

My conclusion is that there is an important distinction between naming a subroutine and invoking it, which is manifested bizarrely by different behaviors in the \&{blah} and &{blah} mechanisms.

blokhead

broquaint: This is amazing. I was looking for such a solution for a while.

Thinking about it, is this canonical? (namely, documented)? or is it a quirk (an oversight in the Perl language design?)

Removing the intermediate assignment to $name, broquaint’s code simplifies to:

use strict;

my $subref = \&{'dynamic'};
&$subref();

sub dynamic 
{
    print "Mmm, dynamic.\n";
}
[download]

which is explicitly documented as an exception to the normal behaviour of strict 'refs' (see strict):

There is one exception to this rule:

$bar = \&{'foo'};
&$bar;
[download]

is allowed so that goto &$AUTOLOAD would not break under stricture.

So, yes, this is canonical.

Hope that helps,

Athanasius <°(((>< contra mundum

Iustus alius egestas vitae, eros Piratica,

my $coderef=__PACKAGE__->can($subname) or die "$subname not found";
$coderef->(...);
[download]

my $subs = {
  "joes_routine" => \&joesub,
  "marks_routine" => \&marksub,
...
};

$subchoice = GetSubToUse();
@args = GetSubArgs();

$subs->{$subchoice}->(@args);
[download]

In case if the variable can contain a reserved word, one could check the variable against a list of all reserved words, before calling it.