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

I've got some poorly modularized code. parta.pm uses partb.pm and partb.pm uses parta.pm. by that, I mean  use something::parta; --as if that wasn't obvious. The inherit-chain (or use-chain in this case) is a bunch deeper than this, but ... for simplicity's sake I shortened it.

Under 5.6.0 (I've recently upgraded) I get an "Unknown Error" and perl fails to compile on the line where it first encounters the use-loop.

Under 5.005 (or something like that) I didn't have this problem... Is there anything I can do? Must I re-write it all so they don't need to inherit each other like that?

Replies are listed 'Best First'.
Re: Chain
by tye (Sage) on Aug 15, 2000 at 01:59 UTC

    Although you should certainly avoid circular dependencies, Perl does fairly well with them (though it is extremely easy to get things wrong when you try stuff like this). Can you reduce the code that generates this problem to a minimal set of scripts and post those? "Unknown error" isn't really a very acceptable response from Perl, no matter what you've done.

            - tye (but my friends call me "Tye")
      Oddly enough, no I cannot. I removed all the circular dependencies. The problem was not solved! I think it has something to do with DBI now. My installation may be crippled, and I think at least one of the modules does a DBI connect before it defines it's subs. ...

      This has been a terribly painful upgrade. *shiver*

Re: Chain
by Adam (Vicar) on Aug 15, 2000 at 00:20 UTC
    Circular references tend to lead to things like core dump. I would look at rewriting these modules so that they are not co-dependant like that.
      I voted you up for that response ... I started re-writing it anyway. But what I was really lookin for was something like this (but a perl solution):
      #ifndef HAPPY #define HAPPY The code that may have already been included elsewhere. #endif
        In that case you would probably want to use eval to run test perl code that would run correctly if your library's function was loaded, otherwise it would bomb. Eval will trap the bomb, and allow you to decide wether or not to lode the library. However, I'd follow Adam's advice :) .

        Caio,
        Gryn

        Are you aware of AUTOLOAD? It is meant for run-time on-demand loading of functions. I abused it in JAPH at the firing range but what you are supposed to do is check $AUTOLOAD and then autoload some functionality.

        There is a standard module Autoloader which can be used to simplify this process if you have a lot of functions you want loaded dynamically at run-time.

        You can use the c precompiler with perl. (-P)

        Or you could put a similar check in the BEGIN block of you package, along with some wizardry to get out of the package from the BEGIN block... maybe a goto or something.   (I wouldn't die or exit there, and returning would just get you out of the BEGIN block, not the package.)