David Christensen:
> Here is a contrived example that shows circular modular dependency
> without circular subroutine dependency:
In this particular case, I'd move subs bar2 and foo2 to another
module FooBar.pm, and have Foo.pm and Bar.pm import those subs
from FooBar.pm instead:
> 2016-10-19 11
On 10/21/2016 05:30 AM, David Cantrell wrote:
> Commit regularly, commit often, don't be afraid to revert or to git
> reset --hard :-)
Agreed.
> I have some rather alarming intra-distribution module dependency
> problems in one of my dists - Number-Phone - but seem to muddle through
> OK. Debugg
On 2016-10-18, 07:05, David Christensen wrote:
Once upon a time, I created a distribution with circular dependencies.
Then I discovered that a compiler failure in one module that is part of
a circular dependency loop will cause a domino effect whereby none of
the modules in the loop will compile
On 10/18/2016 07:51 PM, David Mertens wrote:
> Note: the module Carp::Always can be a lifesaver in the occasion
> that you need a stack trace and don't have one!
[Post reordered for replies.]
I think I knew and forgot that. Thanks for the reminder.
I did recall a technique from "Perl Testing:
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
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. It has a straight-forward
implementation of parallel-named module files (*.pm), documentation
files (*p
11 matches
Mail list logo
