Yes, this is the second option presented in OOP that I
mentioned. :)
However, as Damian Conway writes (and as you note), calling
AUTOLOAD when you mean DESTROY, and when you *know*
what you want to do with DESTROY, is less efficient than just
defining an empty DESTROY method with
sub DESTROY { }
As for ease of maintenance, I would make the case that it is just
as easy to maintain an empty method stub as a special case
in AUTOLOAD, if not easier. And it is certainly clearer when
looking at the code: rather than destruction behavior being
buried in the definition of an AUTOLOAD, you have a defined
DESTROY method to show that there is, in effect, no special
destruction code.
