code coverage and module constructors

[kris]

BCS wrote:
> kris wrote:
[snip]
>> On the other hand, cyclic imports are kinda "poor form" - for want of 
>> a better description. You *can* eliminate them, potentially using an 
>> interface as an intermediary; and probably *should* eliminate them.
> 
> 
> Why are they poor form? (This is a non-rhetorical question, I would like 
> to hear your reasoning.) Putting all your types off by them selves in 
> there own modules can help some. But what about, say, a pair of structs 
> that have methods that take each other as arguments but otherwise have 
> no reason to be in the same module?

Well, my little gripe with cyclic imports is that they tend to 
tighly-couple implementation details. That's very much a 
design-dependent measure, so it's a bit airy fairy for most purposes. 
For example, some designs are intended to be tightly-coupled.

One the other hand, there's something to be said for a large body of 
code that can be cleanly represented as a DAG (no cycles). Tends to make 
the overall system a whole lot easier to extend, easier to decouple as 
necessary, and so on. I suppose it's all about maintenance? Maybe a 
whiff of 'elegance'?  Maybe not.

[snip]

>> I understand where you're coming from on this, and wholly sympathise 
>> since I recently had to redesign a few substantial chunks of code to 
>> eliminate the problem. 
> 
> 
> <nods> I've just lived without static constructors some times.

Yeah ... in my case, I had to get a fairly substantial library working 
with -cov, since it would seem rather bogus for a lib to conflict in 
that respect.

Don't want to get off topic too much, but I found Dimple to be a true 
bobsend for visualizing import-relationships over a large (200+) swathe 
of modules. I've also discovered that attempts to make the diagrams look 
'cleaner' (through refactoring) have an equally pleasant effect on the 
codebase design itself :)