DMD 1.038 and 2.022 releases

[Nick Sabalausky]

"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.