Re: "Dynamic" dispatch tables

I'm not sure why you're using a dispatch table here :-)

sub tcid_1 { say 1 }
sub tcid_2 { say 2 }
sub tcid_3 { say 3 }
sub tcid_4 { say 4 }

my @tcids = 1..3;

my @funcs = map {
    if (not exists &{"tcid_$_"})
    {
        die "Invalid tcid: $_";
    }
    \&{"tcid_$_"};
} @tcids;

for my $f (@funcs)
{
    $f->();
}
[download]

There's no need for a hash if you're just running them in sequence anyway.

Comment on Re: "Dynamic" dispatch tables Download Code

Replies are listed 'Best First'.
Re^2: "Dynamic" dispatch tables by chromatic (Archbishop) on Apr 29, 2011 at 21:06 UTC
I'm not sure why you're using a dispatch table here... The table offers slightly more security, in that there's no possibility of unguarded user input somehow selecting an inappropriate function. Even so, namespacing as you've done ameliorates that somewhat.	[reply]
Re^3: "Dynamic" dispatch tables by sundialsvc4 (Abbot) on Apr 29, 2011 at 22:41 UTC
In this case, I cordially suggest that the concern is not “the use of dispatch-tables per se,” but the authentication that must take place to confirm that a particular dispatch-table entry may be used. When I construct dispatch tables, I usually employ a hashref where each element points to another hashref with several entries in it. One of these of course is a reference to the `sub` that must be called to do the work. Others may be to subs that serve as parameter-validators and security checkers ... you can get as fancy as you like, even setting up arrays of these subroutine references. And then, when the target routine actually does get control, it, too, I believe, has the same duty to check once again that it is being called under appropriate conditions. (Those checks can be simpler, since they basically serve to double-check that the dispatcher is doing its job.) Only requests that have been scrutinized several times, by code that exists in several different places, actually get carried out.
Re^2: "Dynamic" dispatch tables by elTriberium (Friar) on Apr 29, 2011 at 20:26 UTC
You're right, I'm not sure yet if I really need a hash. I'll have to figure out some of the details. I also already started using the "not exists" part, but running into a problem with that: I want to move the setup of the dispatch table / array into a module, but in the module the "exists &{"tcid_$_"} always fails as the sub is not defined in this module. Is there a good workaround for this?	[reply]
Re^3: "Dynamic" dispatch tables by Tanktalus (Canon) on Apr 29, 2011 at 20:55 UTC
Yes. What package will they be in? If they'll be in the Foo package, then just use `exists &{"Foo::tcid_$_"}` instead. :-)	[reply] [d/l]
Re^4: "Dynamic" dispatch tables by elTriberium (Friar) on Apr 29, 2011 at 21:02 UTC
They won't be in any package, but in the .pl script. I got it to work by using "main::", thanks for the hint.	[reply]


laziness, impatience, and hubris
	PerlMonks