Not quite an answer, but I wonder what problem you wish to solve? Generally, when my code starts to get complex and I have to devise something really tricky to get around it, I find that I need to revisit my design. Most of the time, in such a situation, it's a design flaw on my part (of course, it could just be that I'm a rotten programmer, too :).
Not to say that you have poorly designed code. I wouldn't know. I realize that you may simply be asking this for informational purposes.
Cheers,
Ovid
Join the Perlmonks Setiathome Group or just click on the the link and check out our stats.
| [reply] |
heh. for some definitions of "poorly".
Problem:
Trying to allow lazy maintenance of multiple interface
widgets, frinstance Receipt::DoubleA, Receipt::TextOnly,
Receipt::BannerAds, etc
at a level above the widgets, we have an AUTOLOAD
that allows us to call $ui->Receipt->build(%args),
and it will use the Receipt parent class or
choose the right subclass based on external criteria.
The problem is, for example, that we might have a Text
subclass under Receipt, but not have one under Error.
In that case we could - 1) mandate the creation of an
"empty" subclass for every widget for each new interface,
with at minimum an @ISA statement
- 2) descend into some
inelegant evalling or -e testing at some level (perhaps
in the parent widget class), or
- 3) see if there
might be a way to check from upstream if in fact there
was a Text interface for a particular widget before trying
to AUTOLOAD it.
- 4) accept new and novel suggestions from
perlmonks, et al.
Ideally, without keeping a separate registry hash of
available interfaces, of course ;)
As you noted, perhaps too tricky. The extenuating
circumstances of how we got here are lengthy and boring.
{::} =D------an (sometimes the cord just doesn't quite reach)
| [reply] |
| [reply] |
Heh, I just thought of one bizarre way. Note the blessings that end up calling you, or the SUPER calls to you. If you keep track long enough, you'll know.
But I agree with ovid. If this was the answer, you've probably
asked the wrong question. Back up a step.
-- Randal L. Schwartz, Perl hacker | [reply] |
If I recall, it's possible to create a glob that no longer lives in the package symbol table. If that's the case, a treewalk won't be sufficient. Even if it's not possible, you'll
be stucking doing a full symbol table walk, which can't be cheap except for trivially small programs.
-- Randal L. Schwartz, Perl hacker | [reply] |