Bloodnok has asked for the wisdom of the Perl Monks concerning the following question:
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'
|
---|
Replies are listed 'Best First'. | |
---|---|
Re: Inheritable pragma ... or how I learnt perls' compilation order
by kyle (Abbot) on Aug 05, 2008 at 18:37 UTC | |
by Bloodnok (Vicar) on Aug 06, 2008 at 10:01 UTC | |
Re: Inheritable pragma ... or how I learnt perls' compilation order
by Your Mother (Archbishop) on Aug 05, 2008 at 22:16 UTC | |
by Bloodnok (Vicar) on Aug 06, 2008 at 09:54 UTC | |
Re: Inheritable pragma ... or how I learnt perls' compilation order
by dragonchild (Archbishop) on Aug 06, 2008 at 00:23 UTC | |
by Bloodnok (Vicar) on Aug 06, 2008 at 09:26 UTC | |
by stvn (Monsignor) on Aug 08, 2008 at 23:00 UTC |