I have a circular dependency, and am looking for thoughts on breaking
the cycle without (much) redundancy or hard to automate procedures.

I'm developing two programs, Testilence, a unit testing library, and
Amock (library for mock object generation, but that's irrelevant in this
discussion); both programs have unit tests based on Testilence, but
Amock itself should not depend on Testilence, and neither should contain
(or depend on) nontested code.

Testilence contains some utility classes I'd like to use in Amock (or
indeed, anywhere).  I could "fork" them, but would like to avoid this
if at all possible.  I think I can't pull them out into a separate
library for both Amock and Testilence to depend on because that would
create a dependency loop between the utility and Testilence since I'd
like to keep using Testilence for the utility's unit tests.

Both Amock and Testilence are versioned using Subversion, so I could
leave the classes in Testilence and use svn:externals to put them in
Amock too.  That would lead to name clashes if both programs were used
together, and that is a showstopper.

Any ideas?

-- 
How many Vietnam vets does it take to screw in a light bulb?
You don't know, man.  You don't KNOW.
Cause you weren't THERE.             http://bash.org/?255991

-- 
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

Reply via email to