Strategies for resolving cyclic dependencies in static ctors

[Nick Sabalausky]

"spir" <denis.spir at gmail.com> wrote in message 
news:mailman.2690.1300879902.4748.digitalmars-d at puremagic.com...
> On 03/23/2011 12:12 AM, Graham St Jack wrote:
>> Avoiding circularities has plenty of advantages, like progressive 
>> development,
>> testing and integration.
>
> Maybe it depends on your app domain or whatnot; there are lots of cases, I 
> guess, where circularities are inevitable, if not direct expression of the 
> problem.
> Take for instance a set of factories (eg parsing pattern) defined in a M1 
> producing reesults (eg parse tree nodes) defined in M2. It's clear that M1 
> imports M2. Then, how do you unittest M2? You should import M1... Sure, 
> there are various workarounds (creating fake pattern types or objects, 
> exporting the tests in a 3rd module...), but they are only this: 
> workarounds.
>

Funny, I had a couple parsing examples in mind, too: If you have a 
general-purpose (ie, grammar-agnostic) parsing tool, then it may make sense 
for the parse tree nodes (ine one module) to know what Language (from 
another module) they're part of. If it's a grammar-agnostic parsing tool, 
this information can't be encoded in the type. Or, if you have a variety of 
parsing-error-related types (exceptions, for instance), then if they need to 
know what Language they're from, you can't put them in a separate module 
without creating a cycle.

Another thing is string-processing vs general-purpose string-mixin 
utilities: If you have a bunch of CTFE-compatible string-processing 
functions, and a bunch of general-purpose string-mixin-based utilities, it 
makes sense to have them in separate modules. The general-purpose 
string-mixin utilities are almost certainly going to depend on the 
string-processing functions. But if the string-mixin utilities are indeed 
general-purpose, it's likely that some of them may be very useful to the 
string-processing module.

So avoiding cycles can involve some real contortions in certain cases. But I 
do agree they're certainly good to avoid whenever it's reasonable and 
practical to do so.