Strategies for resolving cyclic dependencies in static ctors

[Don]

Graham St Jack wrote:
> On 23/03/11 15:12, Nick Sabalausky wrote:
>> "Graham St Jack"<Graham.StJack at internode.on.net>  wrote in message
>> news:imbai9$2jb9$1 at digitalmars.com...
>>> My own solution to this "problem" is to never have circular imports at
>>> all. The build system I use prohibits them, so any careless introduction
>>> of a circularity is spotted immediately and I refactor the code to
>>> eliminate the circularity. I have never come across a valid need for
>>> circularities, and have never had any trouble eliminating any that creep
>>> in.
>>>
>>> Avoiding circularities has plenty of advantages, like progressive
>>> development, testing and integration. On bigger projects these 
>>> advantages
>>> are very important, and even on small ones they are useful.
>>>
>> That's certainly good in many cases, but I find there are many times 
>> when a
>> "one-way" dependency graph just doesn't fit the given problem and causes
>> more trouble than it solves. You often end up needing to re-invent the 
>> wheel
>> to avoid a dependency, or split/arrange/merge modules in confusing
>> unintuitive ways that have more to do with implementation detail than
>> high-level purpose.
>>
>>
>>
> I'm happy to admit that these cases could come up, but I have never yet 
> seen one where the design wasn't improved by removing the circularity.
> 
> 
I wish Phobos didn't have any circular dependencies. Unfortunately, 
there are almost no modules which aren't in a loop (Basically, anything 
which imports std.range is a lost cause). There is no doubt that it 
hurts debugging.