Hello David, The strategy that I've seen is to place all constants in their own module. (With the many-to-many file-to-package relationship, this isn't a problem.) Then I frankly can't imagine circular dependencies causing trouble. Of course, if one fails, all others will fail too, but failure to compile is BUG #0, and in my experience Perl's diagnostics usually pinpoint the problem without any confusion.
Note: the module Carp::Always can be a lifesaver in the occasion that you need a stack trace and don't have one! The second strategy, if constants really are the source of pain, is to have each module declare all of its constants first, then declare circular dependencies. This way, by the time the compiler reaches any code that needs a constant, all of them will be available. I have no idea if my approach to circular dependencies is helpful. Basically, I've never had problems, so I wonder if there's a design approach you're using that's somehow more prone to this sort of problem with Perl. Again, if you had some code to share, it would help direct the conversation a bit more concretely. --- As for your testing approach, I mostly agree, but work on a function-level heierarchy, not module-level heierarchy. Some functions do not depend upon others; those are the ones I test first. Other functions that call the ones I've test come next, etc. I don't necessarily run these tests in strict order (all 0-level functions before all 1-level functions), but I do make sure to always test simple functions before testing dependent functions. David On Tue, Oct 18, 2016 at 8:54 PM, David Christensen < dpchr...@holgerdanske.com> wrote: > On 10/18/2016 04:37 PM, David Mertens wrote: > > While I appreciate an articulation of best practices, I confess I've > never > > been bitten by trouble with circular dependencies. However, I also never > > export constants, and it might be the case the constants declared among a > > collection of modules, and used among multiple of the same modules, could > > lead to errors. However, I can think of two distinct strategies for > > handling this that would alleviate the issue without sacrificing the > > utility of circular dependencies. > > > > Before I go down that rabbit hole, though, perhaps you could shed some > > light on the kind of problems you've encountered before. Do you have any > > publicly visible projects in which circular dependencies caused > headaches? > > Thank you for your reply. > > > No, I don't have any publicly visible projects in which circular > dependencies caused headaches. > > > I would like to hear your strategies. > > > David > > -- "Debugging is twice as hard as writing the code in the first place. Therefore, if you write the code as cleverly as possible, you are, by definition, not smart enough to debug it." -- Brian Kernighan
