perlquestion
Bloodnok
Hi again, most venerated ones,
<P>
Continuing the line of my submissions for the <EM>idiot question of the decade</EM> award, my next (and I truly believe, best yet) attempt goes as follows...
<P>
I have (been told I have) a requirement for a module that, when inherited from, will...
<UL>
<LI> Fully <EM>support</EM> abstract methods in as much as a call to a non-overridden abstract (by design) method causes the code to <CODE>croak</CODE> or otherwise blow up
<LI> Ensure that the inheriting module is truly abstract in the most draconian way possible i.e. absolutely no constructors allowed.
<LI> Generate errors @ compile (c/w run) time - if at all possible.
</UL>
<P>
The first is/was fairly trivial - via judicious use of a parameterised <CODE>import</CODE> routine initialising a package scoped hash and an <CODE>AUTOLOAD</CODE> routine using said package variable to categorise uncaught method calls.
<P>
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...
<P>
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.
<P>
Shortly thereafter, my co-process gifted me a copy of [Perl Hacks], and whilst reading #47, I guessed that [mod://B::Deparse] (about which I knew nothing) may be put to use in my particular problem.
<BR>
Soooo, without any further thought at all (as will become/is already obvious), my initial reaction was to attempt to rewrite <CODE>import</CODE> to utilise said module against all <CODE>sub</CODE>s/methods in the inheriting class.
<P>
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.
<BR>
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 <CODE>use</CODE>/<CODE>require</CODE> of a separate package file...
<BR>
Anyone seen the root cause of the problem yet (which is more than I had;-) ?
<P>
Yep, that's right, at the time a <CODE>package->import</CODE> is called by the compiler, only the <CODE>BEGIN</CODE> block/<CODE>sub</CODE> 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.
<P>
<EM>.oO(Surely I should've seen that ages ago - DOH!!!)</EM>
<P>
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...:-)
<P>
So come on, you are cordially invited to make the most of this opportunity to support my candidacy for the above award...
<P>
TIA & rgds to all ,
<P>
<EM>Exit, stage left, a goon show fan that wishes he'd chosen the more apposite PM user name of Eccles...as in 'Mad Dan'</EM>
<P>
<div class="pmsig"><div class="pmsig-264639">
A user level that continues to overstate my experience :-))
</div></div>