I realised you were looking for callbacks, but given the number of questions here that are of the form "I want to do X, here's my solution for Y - what's wrong?", I like to give MTOWTDI - just incase what you really want is another WTDI.

Now, on to that last code snippet you quoted. I often mix my inheritance with callbacks. For example, the code I posted in Re: String expansion script is in one of my base objects from which many other object types are derived. In general usage, I call it like this:

  my @strings = $self->expand_string($foo);
[download]

In this module, I'll have my very own expand_variable function which expands the way I want (and usually it defers to $self->SUPER::expand_variable if it can't figure it out). However, in certain cases, I want access to variables that I don't want generic access to - or, perhaps, I can't have generic access to. So I put it my own closure:

  my @strings = $self->expand_string($foo, sub {
    /^VAR1$/ && return $blah;
    /^VAR2$/ && return @some_list;
    $self->expand_variable()
  } );
[download]

This works pretty much everywhere. $blah, @some_list, and $self are all scoped variables for the closure. And even if the current type doesn't have an expand_variable, that's ok since it is derived off the base with default variable handling.

So, from here, there's another minor point I would make with the code you started with: rather than passing in the variable, is it unreasonable to use $_? You may notice my expand_string code does that with do {local $_ = $var; $self->$func()}. I'm not sure which is faster, localising a global, or passing in a parameter. However, that's not why I'm doing it. I'm doing it because it allows your closure to be smaller because so many of perl's functions assume $_ when not given anything else - exactly why you were using "local $_ = shift" in the first place. I'm just suggesting generalising it so that all closures can gain from the behaviour.