John Reimer wrote: > 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.
Being mostly a Java developer, I am well aware of the usage of cyclic dependencies in Java. Although it usually works fine technically, unless the dependencies are in the constructor itself, usage patterns are often made more difficult because of unnecessary cyclic dependencies and/or tight coupling. When porting something from Java, I don't really propose that you fix the errors of the original code, just saying that also the original code in that respect probably has made questionable design decisions. -- Lars Ivar Igesund blog at http://larsivi.net DSource, #d.tango & #D: larsivi Dancing the Tango
