in reply to is there a way to check @ISA from upstream?

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.

  • Comment on (Ovid) Re: is there a way to check @ISA from upstream?

Replies are listed 'Best First'.
(dan2bit) Re: (Ovid) Re: is there a way to check @ISA from upstream?
by dan2bit (Acolyte) on May 10, 2001 at 00:02 UTC
    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]
      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

[reply]
        alas. it would appear that UNIVERSAL::isa and UNIVERSAL::can will not be much help in detecting classes which do not appear in use statements

        use Receipt::TextOnly;
print '#output: '.UNIVERSAL::isa('Receipt::TextOnly','Receipt')."\n";
print '#output: '.UNIVERSAL::can('Receipt::TextOnly','render')."\n";
#output: 1
#output: CODE(0x84baf38)

        [download]

        but 

        use Receipt;
print '#output: '.UNIVERSAL::isa('Receipt::TextOnly','Receipt')."\n";
print '#output: '.UNIVERSAL::can('Receipt::TextOnly','render')."\n";
#output:
#output:

        [download]
        the second code snippet outputs undef. Back to options 1 or 2.

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

[reply]
[d/l]
[select]

In Section Seekers of Perl Wisdom