package Array::Extract;
our $worker_pkg;

...

package Array::Extract::Worker;
BEGIN {
   $Array::Extract::worker_pkg = __PACKAGE__
}
[download]

I didn't know I could do that. Or better: I hadn't thought I could do that. Of course the nice point is that in the BEGIN block I don't need to specify the full package name of $worker_pkg, since our creates an alias to it in all the lexical scope surrounding it.

Similarly, I may still be using a regular lexical variable. I'm wondering if there are any possible drawbacks/differences/gotchas with one approach wrt the other.

Update: I choose BEGIN out of habit, maybe something later like CHECK or INIT might be better, but then again they might cause problems with mod_perl.

I must admit I know next to nothing about those special blocks, and I should probably read up something. Re mod_perl, I'm not a web programmer, but it's good to know anyway. Although I can't understand why: if it's valid Perl, it should continue to work in that environment too...

Similarly, I may still be using a regular lexical variable. I'm wondering if there are any possible drawbacks/differences/gotchas with one approach wrt the other.

Lexical (my) variable: good encapsulation trough limited scope, but you're forced to keep those two packages in the same file. You can't override it from the outside, which can be both good and bad, depending on whether you favor security or extensibility.

For package variables it's just the other way round ;-)

Corion pointed out that this approach does "action at a distance", which you probably can't entirely avoid unless you do symbol table hackery. my variables limit the scope of the spooky action, though.

I must admit I know next to nothing about those special blocks, and I should probably read up something. Re mod_perl, I'm not a web programmer, but it's good to know anyway. Although I can't understand why: if it's valid Perl, it should continue to work in that environment too...

The various compilation and execution phases are a not-so-simple (but really powerful) beast. CHECK and INIT are not executed inside a string eval, which is documented in perlmod, and apparently (I'm not a mod_perl user either) what mod_perl does to execute its scripts and modules.

I don't know if that's a limitation in the implementation or a design goal, though.

Corion pointed out that this approach does "action at a distance", which you probably can't entirely avoid unless you do symbol table hackery.

Actually that's what I (wanted in the first place and) wanted to point out myself in my previous reply -except that I forgot to- to the effect that if I was to adopt that technique, then I would put a well visible comment (and I'm the "self explaining code does not need comments" kinda guy!) besides our $worker_pkg; (or my...)

--
If you can't understand the incipit, then please check the IPB Campaign.

Maybe yet another layer of abstraction might make it even nicer:

package Array::Extract;

my $worker_pkg;
my $priority = -1;

sub import {
    my ($class, %args) = @_;

    if (exists $args{priority}) {
        # Register new implementation

        if ($args{priority} > $priority) {
            $worker_pkg = caller;
            $priority = $args{priority};
        }

    } else {
        warn "Using $worker_pkg, priority $priority\n";
        $class->SUPER::import(ARRAY => $worker_pkg);
    }
}

# Worker.pm
package Array::Extract::Worker;
use Array::Extract priority => 1;

# somewhere else
use Array::Extract::Worker; # has to be used first
use Array::Extract;
[download]

This avoids these global variables that have been described as "action at a distance". Using "priority", you can even have several implementations, and it will choose the one with the highest priority; but that's just an extra bonus, it'll work without priorities too.