1. Identifies which functions have a given use with less work than writing a separate package.
2. Opens you up for refactoring your code later by dynamically creating closures.
3. If you need to later, you can choose to modify the contents of the table hash dynamically without running the risk of namespace conflicts.

And details like that are nothing compared to the crap variable and function names. I mean, conservation is good and all, but a few more letters wouldn't hurt, would it?

my %table = (
    foo => sub { ... },
    bar => sub { ... },
    baz => sub { ... },
    # ...
}
[download]

{
    my ($n, $r);
    no strict qw(refs);
    *{$n} = $r while ($n, $r) = each %table;
}
[download]

Makeshifts last the longest.

In my opinion, the no strict 'refs' solution is the obvious and easy one, and so far the only arguments I have seen against it have been from superstition.

Just for arguments sake :-)

In this module we do not want any arbritary subroutine executed. We just want the "format token" subroutines executable.

At the moment this is not made explicit - it's implicit in the fact that FETCH can only execute single letter functions, and all the format token functions are single letter functions.

We could document this in POD or a comment, but my personal coding philosophy is to, as much as possible, have the code document itself.

As soon as we do:

my %lookup = (  
    a => \&a,
    D => \&d,
    X => \&X,
    x => \&x,
    d => \&d,
    ...
);
[download]

we make the subroutines we want to execute explicit in the code. This is a good thing - and hopefully not just superstition :-)

While I would immediately refactor the subs into the hash as anonymous subroutines I think that that first step is a useful one - and not just monkey code.