DMD 1.038 and 2.022 releases

John Reimer terminal.node at gmail.com
Sun Dec 21 09:05:55 PST 2008


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




More information about the Digitalmars-d-announce mailing list