Recipe 13.8 Invoking Methods Indirectly

13.8.1 Problem

You want to invoke a method by a name that isn't known until runtime.

13.8.2 Solution

Store the method name as a string in a scalar variable and use it where you would use the real method name to the right of the arrow operator:

$methname = "flicker";
$obj->$methname(10);         # invokes $ob->flicker(10);

# invoke three methods on the object, by name
foreach $m ( qw(start run stop) ) {
    $obj->$m( );
}

13.8.3 Discussion

Sometimes you need to invoke a method whose name you've stored somewhere. You can't take the address of a method, but you can store its name. If you have a scalar variable $meth containing the method name, invoke the method on an object $crystal with $crystal->$meth( ).

@methods = qw(name rank serno);
%his_info = map { $_ => $ob->$_( ) } @methods;

# same as this:

%his_info = (
    'name'  => $ob->name( ),
    'rank'  => $ob->rank( ),
    'serno' => $ob->serno( ),
);

If you're desperate to devise a way to get a method's address, you should try to rethink your algorithm. For example, instead of incorrectly taking \$ob->method( ), which simply applies the backslash to that method's return value or values, do this:

my $fnref = sub { $ob->method(@_) };

Now when it's time to invoke that indirectly, you would use:

$fnref->(10, "fred");

and have the closure in turn correctly use the original value of $ob (provided $ob was a lexical variable) that was around when it was created to call:

$ob->method(10, "fred");

This works even if $ob has gone out of scope. This solution is much cleaner.

When using indirect method invocation, it is permitted to store a subroutine reference in the scalar variable instead of a string representing the method name. No verification that the function represents a valid method.

The code reference returned by the UNIVERSAL can method should probably not be used for indirect method invocation on objects other than the one on which it was called, or at least those of the same class. That's because you have no reason to believe that this will be a valid method when applied to an object of an arbitrary class.

For example, this is highly dubious code:

$coderef = $some_object->can("wither");
$other_object->$coderef( );   # wither( ) it even if we shouldn't

That is reasonable only when the two objects are of the same, or compatible, classes. If they were not, and the second did not have a wither method, no exception would be raised, unlike here:

$some_object->wither( );
$other_object->wither( );

Another interesting possibility is to use the strategy outlined in Recipe 12.5 to implement nominally private methods.

my $secret_meth = sub { ... }
sub reg_meth {
    my $self = shift;
    # ... do whatever you want, then 
    $self->$secret_meth(@_);
    # 
}

Because the lexical variable $secret_meth is scoped to the class module's file, code from outside the class cannot access it, and therefore cannot invoke the closure. However, code that is in the module file can see that scalar, so it can use the code reference with $secret_meth to make an indirect method invocation.

When you use a code reference to invoke a method indirectly, Perl doesn't consult a package or its @ISA at all; it just makes the function call and passes in the invocant in the initial slot. That means these two lines are the same:

$self->$secret_meth(@_);        # indirect method invocation
$secret_meth->($self, @_)       # indirect function call

So if you hadn't shifted the invocant off, but had left it in @_, then you could just make the equivalent dereferenced function call yourself:

sub reg_meth {
    # ... do whatever you want, then 
    $secret_meth->(@_);
}

13.8.4 See Also

perlobj(1); Recipe 11.8