Hello Lars,
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 is very often a sign of bad design, it typically mean
(if it is unavoidable), that the modules shouldn't be separated in the
first place. And in D it _is_ a bad idea because static initialization
cannot depend on each other, that is cyclic imports of modules with
static ctors.
And yet it appears practically unavoidable in D in many situations, especially
in porting software that with C, Java, or C++ heritage. Since other languages
don't necessarily have the same module/package concept (except perhaps Java
is the closest), porting such projects over to D inevitably triggers the
cyclic dependency problem. The problem does indeed exacerbate when static
initialization is thrown into the equation.
One would have to build a D project from scratch in order to avoid it (eg
Tango). The majority of projects, however, are going to be based on ported
code. Thus, "bad design" becomes somewhat meaningless practically speaking,
although I certainly wish there were an easy solution to the cyclic imports
other than including all files in the same module. :)
-JJR
