Yes, that is true: the solution relies on having the subclasses at least to execute the parent class DESTROY method though SUPER. Using DESTROY was my best bet because of classes like Class::Accessor that creates code during execution phase. Honestly, I don't know if CHECK and/or END blocks manipulation will not broke code generators more than using DESTROY method...

But iterating all over packages looking for methods that were not override looks like a bit overkill, since the parent class already knows which abstract methods it has. Anyway, how would you do it? I mean, how to mark an method as abstract? Or do you mean to really start checking every package for a "@abstract_methods" (or anything else) available as an indication this class must be checked?

I think an END block might be a minor improvement. You could implement the search any number of ways - probably the easiest would be to create a list of packages that need checking as you go. Then when END comes around you know where to look - similar to @abstract_methods, but a single list of packages.

Another advantage of using END is that it executes once per process, not once per object. A system that uses lots of little objects could get much slower with your code... Also, it will catch missing methods for objects which are not created in the process.

-sam

You got a point with END block... I didn't thought about the performance penalty that might occurs if lots of objects are used (even thought this kind of issue should happen only during developing time).

One thing that occurred me: using END blocks will not be an issue if the program is being executed as persistent way like a server or thru mod_perl, for example?

Alceu Rodrigues de Freitas Junior
---------------------------------
"You have enemies? Good. That means you've stood up for something, sometime in your life." - Sir Winston Churchill