Hello Lars,
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.
Since I'm not a Java developer (or, to be honest, any kind of developer beyond
a language enthusiast), I'd say I'm not in a good position to question the
design decision of Java source that uses cyclic dependencies (such as SWT).
All I can say is that I can agree that it looks like a bad idea because
I can certainly see the painful problems it can produce.
I think what I was trying to say, though, is that I'm genuinely curious how
such design decisions could have been corrected in the original projects
(eg SWT). After working with the code, I do indeed see an incredible example
of "spaghetti" dependencies... but then I'm at a loss figuring out how the
developers could have avoided it, given a language's limitations and the
project's requirements. So I guess I'm a little cautious about wagging my
finger at them. :) My guess is that in such a large project with so many
widgets, if interdependencies were somehow lessoned, the bloat factor might
have increased and, by implication, code reuse decreased. It seems to me
that the project might have grown significantly larger. That's just conjecture,
however. I'm very curious to know how people solve this and why a group
of highly skilled developers felt it necessary to ignore this. The answer
just might lie in SWT's historical roots, I'm guessing, since it started
out from a Smalltalk project at IBM ages ago. Perhaps they experienced the
similar porting "design" decisions that we face now. They were quite possibly
stuck following the object heirarchy/interdepencies already in place.
But I know your intent was to emphasize that it was just one of those questionable
things, not necessarily to be categorically denied any relevance all together.
I can certianly understand why it should be avoided; it has always been
source of annoyance to me whenever I worked on dwt.
I apologize for bringing the focus so heavily on SWT/DWT.
-JJR
