Roman Neuhauser wrote: > 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. isn't there a circular dependency anyway? given that you unit test Testilence with Testilence? if these utility classes are utility classes I wonder whether it's not better if they have no external dependencies? whilst reading about Testilence I remember coming across a mention of runkit ... whilst I wonder whether using runkit for anything other than experimental stuff, could runkit not offer a solution (e.g. renaming the class dependent on the context of it's usage)? probably not, right? > > 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. given that they are the same code would conditional loading of the utlity classes not work? i.e. only load if they don't already exist, this could be augemented with the use of a [number of] Interfaces - if the class already exists and doesn't implement the required interfaces then your code bails out. obviously someone could write classes and interfaces that spoof your actual code/classes/interfaces but then there must a be limit to what your code should/can check for/against. where there is doubt suitable warning can always be generated. at the end of the day your tools are meant to aid developers, in that sense it might be considered acceptable to assume the developer won't purposefully try and break your tools - he/she would only be hurting themselves, no? > > Any ideas? not really ;-) what exactly do these utility classes do? can you point us at a link? > -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
