Hello Yigal,
Nick Sabalausky wrote:
"John Reimer"<[email protected]> wrote in message
news:[email protected]...
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
This might be a naive idea, and wouldn't solve the problems with
cyclic dependancies in the general case: But regarding the static
initializaton issue (which I've come up against myself), what if
static initializers allowed some sort of clause like this:
module foo;
import bar;
// Exact syntax not really important right now
this() dependsOn(bar) {
// Do some initing that depends on
// bar's static initializer having been run.
}
That would force foo's static initialization to be run sometime after
bar's. Obviously, any cycles in the graph of "dependsOn"s would be an
error.
I'm curios - why isn't this a problem in other languages like Java
(and
I assume .net languages as well)?
What's different in D that makes this so dificult? the static
initializers? How is this handled in other languages?
For package scope, ie classes in the same directory, Java does /not/ seem
to need an import statement, so somehow that suggests cyclic imports do not
occur as they do in D for name resolution (in the specific case of package
imports). But I don't know what happens under the hood: does the fact that
Java sees the whole package for symbol resolution imply that it reads in
all symbols initially for a package during compilation? If so, this would
almost be equivalent to D, at compile time, reading all package modules as
if they were one file somewhat similarly to what Derek was suggesting in
another post.
This is too much speculation from me, though. :)
-JJR
