Actually I do have an empty DESTROY but I did not bother copying it. In my case if there is no DESTROY then the program tries to do stuff on a non-existent CGI::Application reference.
The inheritence question is more interesting. Yes I can see my approach makes no special effort to handle inheritence. But actually I think it would work. Let me put my approach in words.
- Avoid AUTOLOAD except where it gives a big gain in loose coupling.
- Don't rely on someone else's module. The area is too complicated.
- This means you have to craft your own solution, but it is fairly simple.
- Define a DESTROY method as bad stuff happens otherwise.
- Define a semantically correct "can" function that either returns undef or a CODE ref.
- Define the AUTOLOAD function in the fairly standard way based upon the "can" function.
- If I were to write a derived class I would either inherit both "can" and "AUTOLOAD" and override less impactful functions; or I would override "can" in the same way and make use of SUPER::can where appropriate.
- I avoid multiple inheritence so I would make autoloading in a multiple inheritence scenario an absolute no.