Continuing the line of my submissions for the idiot question of the decade award, my next (and I truly believe, best yet) attempt goes as follows...

I have (been told I have) a requirement for a module that, when inherited from, will...

• Fully support abstract methods in as much as a call to a non-overridden abstract (by design) method causes the code to croak or otherwise blow up
• Ensure that the inheriting module is truly abstract in the most draconian way possible i.e. absolutely no constructors allowed.
• Generate errors @ compile (c/w run) time - if at all possible.

The first is/was fairly trivial - via judicious use of a parameterised import routine initialising a package scoped hash and an AUTOLOAD routine using said package variable to categorise uncaught method calls.

The latter requirement wasn't/isn't set out in stone, so shouldn't be a problem either way, as for the middle requirement, well that is, as thay say, another matter entirely...

My initial reaction was to pre-judge a set of likely constructor names and parse the inheriting package for any sub(s) by one of these names. I hacked together a .t script containing a number of package declarations, which when run, passed all tests - at this point, I didn't/couldn't suss WTF was going on.

Shortly thereafter, my co-process gifted me a copy of Perl Hacks, and whilst reading #47, I guessed that B::Deparse (about which I knew nothing) may be put to use in my particular problem.
Soooo, without any further thought at all (as will become/is already obvious), my initial reaction was to attempt to rewrite import to utilise said module against all subs/methods in the inheriting class.

The module was re-visited, along with its test harness and I was (admittedly, not entirely unexpectedly) disappointed to observe that some of the tests failed.
Eventually, it dawned on me that the successful tests all involved packages declared in-line in the .t script, or put another way, the tests that failed involved the use/require of a separate package file...
Anyone seen the root cause of the problem yet (which is more than I had;-) ?

Yep, that's right, at the time a package->import is called by the compiler, only the BEGIN block/sub exists in the inheriting class when it [the inheriting class] is implemented as a disparate package file - the compiler is busy determining dependencies and preloading the symbol table ready to begin the ascent of compiling the package itself.

.oO(Surely I should've seen that ages ago - DOH!!!)

My current thinking (or what passes for it in my world) is that I probably need to beg/borrow/steal, or possibly write, a module that acts as an inheritable compile pragma to any sub-class - unless you know better...:-)

So come on, you are cordially invited to make the most of this opportunity to support my candidacy for the above award...

TIA & rgds to all ,

Exit, stage left, a goon show fan that wishes he'd chosen the more apposite PM user name of Eccles...as in 'Mad Dan'