I do not want to implement DESTROY, that's the point. :-) What I want to avoid is to croak with "missing method" during object destruction. The reason I want to make an exception for DESTROY in AUTOLOAD is the following scenario:

{
    package Foo;

    sub new { ... }
    sub DESTROY { ... }
}
{
    package Bar;
    our @ISA = Foo::;

    sub AUTOLOAD { ... }
    sub DESTROY {} # Oops.
}
[download]

I want to think as little as possible, and by adding the exception in AUTOLOAD it always works and is future proof should you add any DESTROY later.

This is exactly what I do not trust. It seems that one class is trying to be very clever. It just feels wrong.

I'm not sure what you are referring to. Is it the call to UNIVERSAL::can? If UNIVERSAL::can($obj, 'foo') returns a value then that is what $obj->foo will call by the definition of UNIVERSAL::can. So naturally I would not want my can to return anything else if I want to be consistent.

In fact I was afraid I was not being clever enough and was missing something. The only thing my can does differently from any method that adds to a super method is that it checks UNIVERSAL::can:

• If $obj->$method will not call a regular method and if this class autoloads $method: go to it.
• If not: see what the next class says. (UNIVERSAL is considered the top class; explicitly added as the return value only because next::method ignores UNIVERSAL.)

AUTOLOAD's only exception is about DESTROY:

• If this class autoloads the method: go to it.
• If not: ask the next AUTOLOAD.
• If no next AUTOLOAD: croak, unless the method is DESTROY.

lodin