dan2bit has asked for the wisdom of the Perl Monks concerning the following question:

Is there some place (under the covers, perhaps?) where a class (Me) could discover at runtime what other classes have Me in their @ISA, or is it purely a one way street?

{::} =D------an (sometimes the cord just doesn't quite reach)

  • Comment on is there a way to check @ISA from upstream?

Replies are listed 'Best First'.
(Ovid) Re: is there a way to check @ISA from upstream?
by Ovid (Cardinal) on May 09, 2001 at 23:37 UTC

    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.

      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)

        Would UNIVERSAL::can help here at all? And perhaps understanding that when you define AUTOLOAD, you should also override can?

        -- Randal L. Schwartz, Perl hacker

Re: is there a way to check @ISA from upstream?
by merlyn (Sage) on May 09, 2001 at 23:39 UTC
    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

Re: is there a way to check @ISA from upstream?
by merlyn (Sage) on May 09, 2001 at 23:33 UTC
    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