Re: circular dependency between libraries

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



ok, I'm starting to grok it now :-)

Roman Neuhauser wrote:

...

>> from looking at runkit it would seem using runkit_import() would work,
>> it would mean you simply 'include' the utility class(es) in both Testilence and
>> Amock using runkit_import() and that would simply cause the second 'include'
>> to overwrite the class definition of the first include.
> 
> That is evil.  You have installed Testilence, it works.  You install
> Amock, Testilence broke.  Reason: incompatible versions of the utility.

ah yes I see what you mean.

...

> 
>>> So far I'm leaning towards pulling the utility out from Testilence,
>>> sacrificing the ability to unit test the library without jumping through
>>> hoops.
>> that seems sane - hopefully the utility won't change half as often as
>> the 'real' tools and given that you test the utility yourself before packaging
>> you know that it works ... maybe including your test results in the utility
>> package is something to consider?
> 
> I'd include the tests of course.  The steps would then be:
> 
> install utility + its tests: no tests are run
> install Testilence + its tests: both utility's and Testilence's tests
>  are run before anything is installed
> 
> For other users of the utility, such as Amock:
> see above, plus:
> install Amock + its tests: both utility's and Amock's tests are run
>   before anything is installed

my gut says that it would be easiest to just keep to seperate copies of
the utility class(es) one for each project, although it kind of depends
on how large & complicated the utlity is ... this would remove all the described
problems and leave you with only the 'slightly' inelegant situation where you
have to, internally, sync the [relevant parts of the] 2 codebases now and again.

given that there is a possibility of different version of the utility being
required (as per you 'That is evil' reply) the '2 seperate copies of the codebase'
approach might be simplest and most reliable way of tackling the problem ...
again (AFAIKT) this mostly comes down to you personally being able to accept
the relative inelegance of the solution.

I'm trying to act as an extra braincell here - forgive me if what I'm saying is
way too simple to be worthwhile :-)

> 

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


[Index of Archives]     [PHP Home]     [Apache Users]     [PHP on Windows]     [Kernel Newbies]     [PHP Install]     [PHP Classes]     [Pear]     [Postgresql]     [Postgresql PHP]     [PHP on Windows]     [PHP Database Programming]     [PHP SOAP]

  Powered by Linux