Hello Sean,
bearophile wrote:
Walter Bright:
Excess isn't the problem, I want to see if import cycles is.
Generally all the modules in my dlibs import each other. This is
nearly unavoidable, if a module contains string functions, and
another one contains math stuff, the string module will want to use
some math stuff and the math module may need string representations
and processing. In the D specs I haven't seen an advice to not use
cyclic imports, so I don't want such compiler flag, I prefer a
compiler able to manage such cyclic imports efficiently.
Cyclic imports are a bad idea in general because of the impact they
have on verifiability (unit testing). But as you say, sometimes
they're unavoidable.
Sean
I'd going to wager that they are /often/ unavoidable, especially in ported
projects from other languages that have either no concept or a different
concept of modules/packages.
DWT is perhaps the single worse example of cyclic imports. I'm not sure
how the design could have been improved in Java's SWT. All it takes is the
need to reference one symbol in each module (because each object apparently
needs to just "know" about the other) to create a cyclic import issue in D.
Static initialization has also been a problem in DWT such that a few significant
workarounds were necessary.
I agree that the interdepencies should be avoided in all new projects designed
specifically for D. I'm just not sure what the solution would be for the
great mass of ported software.
-JJR
