in reply to Is it possible to call a package::main subroutine from a module?

First, a couple of things: Always use warnings;. Avoid using $_[0] etc. directly unless you know why you need to, instead do sub foo { my ($x,$y,$z) = @_; ... }. Don't turn off strict for the whole module, just do it in as small a scope as possible. (And in fact, in this case, you don't even need to turn it off at all, since you're not accessing subroutines via their name, you're accessing them via a code reference, e.g. \&get_locations.)

In general, you probably should study perlreftut and perlref. The way to call a code reference is $coderef->($arg1, $arg2, ...), where $coderef can also be a complex dereference consisting of hashes, arrays, and calls to other code references.

# ---8<--- ProcessData.pm ---8<---
package ProcessData;
use warnings;
use strict;
use Carp;

sub new {
    my ($class) = @_;
    my $self = { _dispatch_table => {} };
    return bless $self, $class;
}

sub add_subroutine {
    @_==3 or croak "Insufficient arguments passed to add_subroutine().
+";
    my ($self,$name,$code) = @_;
    croak "The reference passed to add_subroutine() is not a CODE refe
+rence."
        unless ref $code eq "CODE";
    $self->{_dispatch_table}{$name} = $code;
}

sub process_data {
    @_==2 or croak "Insufficient arguments passed to process_data().";
    my ($self,$name) = @_;
    $self->{_dispatch_table}{$name}->();
}

sub process_locations {
    my ($self) = @_;
    $self->process_data("locations");
}

1;

# ---8<--- test.pl ---8<---
use warnings;
use strict;
use ProcessData;

my $pd = ProcessData->new();
$pd->add_subroutine("locations", \&get_locations);
$pd->process_locations;

sub get_locations { print "get_locations...\n" }

[download]

Replies are listed 'Best First'.
Re^2: Is it possible to call a package::main subroutine from a module?
by TorontoJim (Beadle) on Mar 21, 2016 at 23:05 UTC

    Thank you. I'll try this out.

    Can you tell me why it's better to use sub foo { my ($x,$y,$z) = @_; ... } instead of $_[0] ?

    I've been using $_[0] for twenty years and never heard of an issue with it ... but then I can be thick sometimes.

[reply]
[d/l]
[select]

      It's not always a Bad Thing to use $_[0] directly, but there are several really good reasons not to. I'll let Perl::Critic::Policy::Subroutines::RequireArgUnpacking explain:

      Subroutines that use @_ directly instead of unpacking the arguments to local variables first have two major problems. First, they are very hard to read. If you're going to refer to your variables by number instead of by name, you may as well be writing assembler code! Second, @_ contains aliases to the original variables! If you modify the contents of a @_ entry, then you are modifying the variable outside of your subroutine. For example:

      sub print_local_var_plus_one {
    my ($var) = @_;
    print ++$var;
}
sub print_var_plus_one {
    print ++$_[0];
}

my $x = 2;
print_local_var_plus_one($x); # prints "3", $x is still 2
print_var_plus_one($x);       # prints "3", $x is now 3 !
print $x;                     # prints "3"

      [download]

      This is spooky action-at-a-distance and is very hard to debug if it's not intentional and well-documented (like chop or chomp).

[reply]
[d/l]
[select]
        Thank you for explaining. I learned that lesson about the modification of the original variable the hard way many years ago. Sometimes it's good to be reminded, though.
[reply]

In Section Seekers of Perl Wisdom