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
On 10/18/2016 04:53 PM, James E Keenan wrote:
> At this point I feel compelled to ask:
>
> Why?
>
> Why do you want to design a library with so many exportable subroutines
> and (worse!) constants?
>
> Now, I concede that the statements above are merely background for your
> questions about circ
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, a
On 10/18/2016 02:05 AM, David Christensen wrote:
module-authors:
I am in the process of writing a Perl distribution that currently
contains a dozen or so packages, several dozen exportable subroutines,
and over a hundred exportable constants.
At this point I feel compelled to ask:
Why?
Why d
Hello David,
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 modu
On 10/17/2016 11:05 PM, David Christensen wrote:
> I have applied a hierarchical module dependency architecture to avoid
> circular dependencies:
>
> 1. Modules and test scripts that do not depend upon any other
> modules within the distribution are "dependency level 0".
>
> 2. Modules and test
