If you don't want to go there, then you'll need to write a function that walks the symbol tree yourself. And you'll need to know inside the function what package it is installed in. This could be done with an import method that looks like:

sub import {
    my $package = shift;
    my $methodname = shift;
    my $dest = caller;

    my $method = sub {
        return super($package, "blah", @_;
    };

    my $symbol = $dest . '::' . $methodname;
    {
        no strict 'refs';
        *$symbol = $method;
    }
}
[download]

Honestly this is so much work that I really would advise the eval solution here.

That function that walks the symbol tree is what NEXT is supposed to be. I don't know why it doesn't like this scenario. What exactly do you mean, use eval to compile it into the package? Something like this?

sub import {
    my $package = shift;
    my $methodname = shift;
    my $dest = caller;

    eval <<END
package $package;
sub $methodname
{
    return shift->SUPER::blah();
};
1;
END
}
[download]

That seems to work. I was hoping my imported symbol could make use of closure variables, but I guess I could just interpolate them into the eval.

NEXT doesn't like this because it uses caller to find the calling package, and caller sees the package the function was compiled in, not the one that was called.

You have the right idea with the eval approach, but I was suggesting something more like this:

sub import {
    my $package = shift;
    my $methodname = shift;
    my $dest = caller;
    my $compiled_in = __PACKAGE__;

    # The initial comment improves error messages.
    eval qq{# line 1 "Loaded by $compiled_in\::import"
        package $package;
        sub $methodname {
            return shift->SUPER::blah();
        }
    };
    die $@ if $@;
}
[download]

Also note that your imported symbol can make use of closure variables without interpolating them. If you put \$foo in your code, that will be compiled as $foo, and that will pick up any lexical $foo that is in scope when the eval happens.

The SUPER module handles this case.

Thanks for maintaining this module on CPAN and for noting its usefulness here.

I think the module's documentation (SUPER) could be made a lot clearer. For example, your reply appears to contradict the module documentation (original emphasis included):

Note: you must have the appropriate package declaration in place for this to work. That is, you must have compiled the method in which you use this function in the package from which you want to use it. Them's the breaks with Perl 5.

But perhaps that caveat doesn't apply to one or more other features of the module? That kinda makes sense since this caveat appears under the documentation for the super function (the super method appears in sample code but otherwise doesn't appear to be documented?). But that interpretation is rather at odds with "Them's the breaks with Perl 5." So I'm not completely sure how I'm supposed to interpret that.

As another example, the phrase "Call it directly." is much less clear than including actual code that demonstrates the proper way to call something.

I'd also more clearly mark sample code that is not demonstrating how to use the module. For example, include a comment in such sample code:

# Without this module you'd write:
$self->SUPER::method(@_);
[download]

since the sentence(s) above the code block are so much less prominent to the eye.

I'm also unsure how SUPER() becomes a method of my class. There is no documentation of how one invokes the module itself (I can tell that 'use' is required but it would be nice to state that and even give better hints about what arguments can be passed in when the module is used). I'm guessing that I'm not supposed to inherit from the module.

I assume that "all parents" means "the names of all (immediate?) parent classes" but that just leaves me wondering why $class is passed into it (rather than it just using ref($invocant) -- or is that supposed to be the current class that should be skipped, ie. what __PACKAGE__ would be if you didn't need this module?). There are several hints that "immediate" applies (indeed, "parent" is not "ancestor"). And I'd prefer to see the order used to search the hierarchy spelled out.

I suspect most of this would become clear to me if I just gave in and read the source code, but it would probably be better for this to not be a requirement for understanding the module.

Thanks, again.

- tye        

From skimming the module documentation it looks like you should be able to do this:

$some_package->super("some_method")->($obj, @arguments);
[download]

which would fill in all of the "walk the symbol table" bits in the second option that I gave you for how to solve this.

I wouldn't have noticed that if I hadn't read carefully with the expectation that chromatic was almost certainly right that it could indeed solve your problem.

IIRC, most of the problems I encountered were resolved by changing use base qw/foo/; to use foo; our @ISA = qw/foo/; and also changing require... to use....

I reasoned, probably wildly inaccurately, that the change allowed perl compile-time access to the used class packages, hence it [perl] could resolve the method names earlier.

Just my 10 penn'orth