tilly

First, I will say that if you are using multiple-inheritance in the presence of AUTOLOAD then you are already in trouble. Sure, you should be able to do it, but IMO thats being idealistic. Part of the difficulty of multiple inheritance is managing the dispatching of methods and name clashes, if your methods aren't even implemented (and handled with AUTOLOAD) your just asking for it.

As for how to implement local can without breaking it elsewhere, I don't see what the problem is. This (untested) code below (written waaaay past my bedtime) should serve as a stating point:

sub can {
    # ------------------------------------
    # this is the code tilly is talking about below
    # sorry , it was late
    # ------------------------------------
    # my ($calling_package) = caller();
    # if ($calling_package eq __PACKAGE__) 
    # ------------------------------------
    # however, this is what I meant ...
    my ($self, $method_name) = @_;
    # if this is called with by an object specifically
    # blessed into this __PACKAGE__, then we 
    # will handle this because of AUTOLOAD
    if (ref($self) eq __PACKAGE__) {
        return my_special_can_that_plays_nice_with_AUTOLOAD(@_);
    }
    else {    
        return $self->SUPER::can($method_name);
    }
}
[download]

Now I am making the assumption that SUPER::can will work, but its alot easier to control where you inherit from then it is who inherits from you. If SUPER::can doesn't work, then do something that does work.

I will say again, can should work, period, end of story. If it doesn't work (because you used AUTOLOAD or even some symbol table madness) then you need to re-think your design.

-stvn