You are wrong. The SUPER module on CPAN does not depend on what package was used at compile time. That is the point to the module. The SUPER module is not the same thing as SUPER:: that is listed in your perl documentation. You can't read perlobj (and related) and know what SUPER does.

According to the docs for SUPER:

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.

And when i tried it, it didn't work.

There is more than one way to use SUPER than the super() function. super() happens to be nice to look at but does suffer from that drawback. Use the $self->SUPER and $self->super methods instead. Those *don't* suffer from that problem.

⠤⠤ ⠙⠊⠕⠞⠁⠇⠑⠧⠊

...
my ($class, $alias_for) = @_;

my $sub = eval "package $class;" . <<'__EOI__';
   sub {
      my ($class, $params) = @_;
      do_something_with($alias_for);
      return $class->SUPER::find_ids($params);
   }
__EOI__
die $@ if $@;

install_sub(
   $class,
   'find_ids', 
   $sub
);
...
[download]

When I tried this

    my ($class,$alias_for) = @_;

    eval "package $class;"<<'SUB';
        sub find_ids {
            my ($class,$params) = @_;
            # Do something with $alias_for
            return SUPER::find_ids->($class,\%params);
        });
SUB
[download]

it gives me the message:

Variable "$alias_for" will not stay shared at ...

( Sorry, this post is completely wrong. )

That's a different problem, relating to threads and shared variables.

Is $alias_for a shared variable? I'm no threading expert, but it makes sense that captures do not remain shared. Perhaps you want to capture a reference to the shared variable instead of capturing the shared variable itself.

    my $alias_for_ref = \$alias_for;

    eval "package $class;"<<'SUB';
        sub find_ids {
            my ($class,$params) = @_;
            # Do something with ${$alias_for_ref}
            return SUPER::find_ids->($class,\%params);
        });
SUB
[download]

The problem with this, is that SUPER refers to the @ISA of the class it is COMPILED into, not the class of $self at runtime.

This is the only sensible way for it to work.

You don't want to find the same named method in the superclasses of the object. You must find the same named method in the superclasses of the class in which you are compiled.

Consider X @ISA Y @ISA Z. Now, call method doit on an X, which isn't found, so we go up to class Y. In Y::doit, we want to call SUPER::doit. We cannot look at the @ISA of the object (which is an X), because that'll come right back around to us again! We must look in the @ISA of the class to which we belong (in this case, Y::doit), yielding a potential call to Z::doit.

So, if I'm following what you're trying to do, you'll be making classes that cannot be subclassed properly, because they'll be looking at the class of the object to get parents, not the "class" of the method. Broken.

I'm not sure why you think this is "a problem".

This is the only sensible way for it to work.

Was that sarcasm? The current algorithm has some bizarre fetish for static code, which is a bit odd to encounter in a dynamic language with late binding everywhere else. It makes calling the parent method from methods defined in roles very difficult, for example.

A working algorithm would search for a possible parent method in the list of MRO candidates after the current point of call. Note that this is sort of pretty much exactly like SUPER does.

The problem is that I want to dynamically generate a sub that would APPEAR to have been compiled into package X (and so inherit package X's @ISA), even though it was actually generated in package Y.

But my anonymous sub also relied on the state of the variable $alias_for at compile time. And when I tried a string-eval on the sub, it complained that $alias_for would not stay shared, ie you can have your cake or eat it, not both...

Thanks to ikegami for showing me how to have both.