DMD 1.038 and 2.022 releases

[Sergey Gromov]

Mon, 22 Dec 2008 00:07:42 +0200, Yigal Chripun wrote:

> 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?

In C/C++, if headers include each other and don't have any protection
from multiple inclusion, they will include forever.  If they *do* have
protection, you get weird errors about unknown symbols which are
obviously should be known.  Only experience may tell you what happens.

In Java ME used in mobile phones, when class A is loaded, its static
initializers are run.  If they refer to a class B which is not loaded
yet, class B is loaded and its static initializers are run.  If B's
initializers refer to static fields of class A, they consider A already
loaded and get uninitialized values.  That is, crash at run-time.  I
don't know what Java SE does in this case.