Oops! I was thinking of another warning.

It turns out the warning is spurious in this case. We want a class's find_ids to refer to $alias_for as it was when find_ids was compiled, which is to say we want $alias_for not to be "shared".

The warning can be silenced by changing

sub find_ids {
[download]

*find_ids = sub {
[download]

Tested.

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

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

Thanks ikegami - that works a treat.

When I benchmarked the three methods, I got this:

          Rate super  eval  orig
super   7794/s    --  -88%  -93%
eval   67568/s  767%    --  -35%
orig  104167/s 1236%   54%    --
[download]

... where super is using SUPER, eval is ikegami's method, and orig is the one in the original post.

The eval method would be preferable because it checks the @ISA at runtime, while my method, although faster, would only check @ISA at compile time.

UPDATE At ikegami's suggestion, I have added the benchmark code:

Read more... (2 kB)

Are you benchmarking the creation of the function, its call or a likely combination of both?

I tend to ignore benchmarks results for which I haven't seen the benchmark code. How else can their correctness and relevance be judged? Writting good benchmarks is hard.

I usually place the benchmark code in <readmore>..</readmore> tags in the same post as the benchmark results.