Most likely a better solution would be to use object oriented techniques. Define an "interface" (methods that are expected to be supplied by an object) then have each of your "worker" modules register themselves when they are loaded by pushing a worker object into a list. Something like:

use strict;
use warnings;

our @Workers;

package Worker1;

push @Workers, Worker1->new();

sub new {
    return bless {}, __PACKAGE__;
}

sub doStuff {
    print __PACKAGE__ . " reporting for duty\n";
}


package Worker2;

push @Workers, Worker2->new();

sub new {
    return bless {}, __PACKAGE__;
}

sub doStuff {
    print __PACKAGE__ . " standing by\n";
}


package main;

for my $worker (@Workers) {
    $worker->doStuff();
}
[download]

Prints:

Worker1 reporting for duty
Worker2 standing by
[download]

In practise each package would be in a different module file. Now each worker object keeps its own state so globals aren't needed.

Why are anonymous subs more acceptable?

Since subs are package-scoped in Perl 5, the inner subs are visible from the outside. Which means that they are visible before the outer sub is run, which is why they can't easily be a closure over the variables from the outer sub.

Which is why anonymous subroutines are safer in this case.

use strict;
use Digest::SHA 'sha1_hex';

sub get_hash_printer
{
   my $str  = shift;
   my $hash = sha1_hex($str);
   return sub {
      print "$hash\n";
   }
}

my $hash_printer = get_hash_printer("Hello");
$hash_printer->();

__END__
f7ff9e8b7bb2e09b70935a5d785e0cc5d9d0abf0
[download]

Hm, okay that makes sense. I will probably be fine implementing it like this then. Just wanted to know if there were any major pitfalls or get some insight into an alternative implementation.

The major pitfall is that, if you ever call the outer sub more than once per process, then the inner sub will not be sharing any lexicals defined within the outer sub, hence the "won't stay shared" warning. So be sure to enable warnings.

- tye