I'll skip the suspense and just tell you the specific answer to your problem, though: you have to wrap your @ISA = 'Exporter' and @EXPORT = ... bits of code in a BEGIN block. Look at the example below (to which I've added some verbose information, so that you can really see what's happening):

me@host> perl -c XXA.pm 
Beginning XXA compile
  Beginning XXB compile
    Beginning XXA compile
      Just used XXB in XXA compile
Bareword "xxb" not allowed while "strict subs" in use at XXA.pm line 2
+6.
BEGIN not safe after errors--compilation aborted at XXA.pm line 29.
BEGIN failed--compilation aborted at XXB.pm line 15.
BEGIN failed--compilation aborted at XXA.pm line 15.
me@host:>
[download]

That's basically the situation you are in currently. Now, go and un-comment the BEGIN keyword before the Exporter blocks in those modules...

me@host> perl -c XXA.pm 
Beginning XXA compile
  Beginning XXB compile
    Beginning XXA compile
      Just used XXB in XXA compile
     Finishing XXA compile
    XXA->import called
    Just used XXA in XXB compile
   Finishing XXB compile
  XXB->import called
  Just used XXB in XXA compile
 Finishing XXA compile
XXA.pm syntax OK
me@host>
[download]

Voila! Problem fixed. This should really be in some sort of FAQ, somewhere... I've gotten into arguments with VERY experienced perl programmers about this very topic before (that you must *ALWAYS* but your @EXPORT and @ISA in begin blocks (or use base.pm for your @ISA declarations)).

------------
:Wq
Not an editor command: Wq
[download]

You have gotten into arguments before, and you're about to again.

You have set up a bad design and found one way out of a problem that it causes, and then you think that way is how everyone should do it. This is wrong.

The real moral is that circular dependencies are a Bad Thing. They cause lots of complexity, and compilers don't like dealing with them. That is true in virtually any language! Avoid having circular dependencies and you'll avoid running into many subtle and strange issues.

Secondly there is another way out of your issue. Rather than putting manipulations of @ISA into BEGIN, you could switch from use to require. This not only solves you problem, it also gives you a shot of successfully handling the situation where one module actually calls functions in the other in setting up class variables. OK, it doesn't guarantee that (see what I said above about circular dependencies), but you have a chance.

Thirdly there are other issues with BEGIN blocks that you're ignoring. People disagree on them, but if you read (tye)Re: Supersplit carefully you'll see that there are subtle issues with, for instance, error reporting which make it desirable to avoid playing subtle BEGIN games.

So avoid circular dependencies and don't play subtle BEGIN games. Your code will be less complex and it will work better. Furthermore if you move into other languages, this habit will avoid your having to worry about nasty corners of how they deal with circular dependencies. (A few handle it smoothly, some break, some handle it but you get fragility as a result. Perl falls into the last category.)

You have set up a bad design and found one way out of a problem that it causes, and then you think that way is how everyone should do it.

To be pedantic, it was Petamem that set up a bad design; etcshadow was just suggesting a way out that didn't involve redesign (redesign probably being a suggestion that would be ignored). Sometimes bad design just has to be coped with.

Well, as to the bit about the arguments... they've really not been about questions of circular dependancies, but rather about the specific question at hand (importing from a module that imports from you), and the necessity of setting up of your exports at compile-time. That's why I happened to have a fairly detailed example of this imediately at hand.

As to the outright condemnation of circular-uses, I have to respectfully disagree. In managing a complex project, it can become a fairly arbitrary line to draw between your modules. It forces you to structure your code-containers around your code's calling-graph, rather than around the functional nature of your code.

I spend most of my time writing code for healthcare, so here is a simplified example: I want to be able to group code for patients in a Patient module, and code for claims in a Claim module. There are perfectly reasonable cases which require the processing of a claim to have to access patient functions, and vice-versa. Patient's have claims, and the description of a patient is not complete without his/her claim-history. When displaying a claim, I need to access the patient's information, as it is a fundamentally important part of the claim. If I understand your "circular uses are bad, 'mkay" correctly, then I should not be allowed to organize my code this way.

Also, as to the comment that other languages do not allow circular dependancies, that's just not true (in my experience). Certainly *some* other languages will not have a means to allow for it... but *some* other languages do all sorts of crazy things and impose limitations that I don't ever want to deal with as a user of that language. Even a language which provides as little in the way of facilities to the programmer as C has a means for dealing with circularly dependant libraries. First, there is a separation between headers and code... that goes a long way, on its own. Second, a fairly simple method for preventing pre-compiler infinite-loops is employed:

#ifndef some_token_i_use_to_represent_this_file
#define some_token_i_use_to_represent_this_file 1

  /* your code goes here */

#endif
[download]

So, C, and any language which inherits it's basic separation of header files and code files from C, along with a pre-compiler as capable as C's is set. It can handle circular dependancies.

I guess that gets somewhat to a larger point about this question (as well as some of the issues you raised with circular uses in perl): different languages do things differently with respect to this, and in many of them (all, maybe), there is a necessary discipline to build atop the language, itself, to protect yourself from problems. In perl, this discipline includes understanding the difference between BEGIN time and run-time, and using that understanding appropriately. Maybe perl requires a little bit too much in the way of requiring discipline from its programmers, in this regard... on that I won't comment. It certainly wouldn't be the first time perl's been accused of requiring self-discipline of its programmers, rather than enforcing discipline upon them.

However, I actually don't think that there is anything all that wrong with publishing some best practices as a way to encourage that self-discipline in people who haven't yet attained the understanding of why that self-discipline is necessary. In my mind, telling people to always put their @ISA and @EXPORT setup in a BEGIN block is kind of like telling people to use strict. Actually, a better comparison would be like telling people to NEVER put a "my" operator in a conditional. The reason why it's important to do this is tricky to divine on your own, and may not bite you imediately. Still, there's no harm in doing it, and it may (proably will) prevent errors, later.

------------
:Wq
Not an editor command: Wq
[download]