DMD 1.038 and 2.022 releases

[Yigal Chripun]

Nick Sabalausky wrote:
> "John Reimer"<terminal.node at gmail.com>  wrote in message
> news:28b70f8cfcfe8cb30c0a0e2ac70 at news.digitalmars.com...
>> 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?