You ignored the alternate require solution. You ignored the error reporting issues with BEGIN type games which argue for not playing them. You dismiss the existence of languages that don't handle circular dependencies. (I believe that PL/SQL is one.) You don't seem to be aware that your solution doesn't solve all of the issues with circular dependencies in Perl. (Example, suppose in your example that a Patient has claims, and a claim has a Patient. Both of those are cached for efficiency. Guess what? You have a memory leak!)
As for your example, there are plenty of ways of handling this. For instance you can have a module that you're supposed to use which does all of the other uses for you, in the right order. Or you can use an OO style which avoids the need to export anything and makes circular dependencies not quite as bad. Or you can use lazy loading so that dependencies are resolved as they're about to be called. And often you can find a design which avoids the circular dependency entirely. (Rule of thumb, in a good design each module will call few others, but will be called from many other places. If this is achieved, then circular dependencies become unlikely.)
Any of these solutions can be sufficient. All of them avoid having to think hard about compile vs runtime. All of them avoid the error reporting problems that I pointed out can happen with BEGIN games.
Given the existence of alternatives, I'd prefer to not make recommendations that make code more complex and cause problems of their own for the possibility that someone will create grief. Instead I'd prefer to suggest the discipline of avoiding creating circular dependencies, and then let people know what problems they create when you do cause them.
In reply to Re^4: Serious Exporter Problems
by tilly
in thread Serious Exporter Problems
by PetaMem
| For: | Use: | ||
| & | & | ||
| < | < | ||
| > | > | ||
| [ | [ | ||
| ] | ] |