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 { }
[download]

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.