QtD 0.1 is out!

[Yigal Chripun]

Fawzi Mohamed wrote:
> On 2009-02-27 21:49:58 +0100, Fawzi Mohamed <fmohamed at mac.com> said:
>
>> On 2009-02-27 21:10:29 +0100, Walter Bright
>> <newshound1 at digitalmars.com> said:
>>
>>> Eldar Insafutdinov wrote:
>>>> Now we have to make a manual init function called from class
>>>> constructors. I understand that allowing static consructors with
>>>> cyclic imports will make order of their execution undefined, but this
>>>> is acceptable and actually semantically doesn't break the idea of
>>>> cyclic imports. Otherwise in my opinion this behavior is
>>>> inconsistent..
>>>
>>> One of the goals of D is to eliminate undefined behavior wherever
>>> possible. In C++, the undefined order of static construction was a
>>> source of many porting problems. I think it's better in the long run
>>> to have a defined order, even if it means having to reorganize the
>>> code a bit.
>>
>> I fully agree,
> *avoiding*
>> circular dependencies between modules is in general a good practice:
>> a circular dependency it means that you have tight coupling, in in
>> that case it is normally better to have everything in the same module
>> to have a better control on it.
>> Sometime one has cases in which circular dependencies arise, two ways
>> to get rid of them are for example:
>>
>> 1) define and interface, the circular dependency is in the interfaces
>> that are described in the same module, the two (or more) modules
>> include the interfaces, and are not directly dependent on each other
>> (only through the interfaces)
>>
>> 2) use templates, the circular dependencies are on a template
>> parameter. The circular dependencies arise only upon instantiation
>
>

I agree with the above but there is still a small issue here:
A module is a single file and when you have several large classes that 
are tightly coupled you can get a very big file with thousands of lines. 
what if i want to put each class in its own file?
besides, the notion of a module is somewhat redundant - it's 
functionally a static struct.

this is related to D's compilation model which is copied from C/C++ and 
it seems to me that this model is outdated. C#'s model of assemblies and 
metadata seems more capable. for instance there's no need for header 
files, that info is stored in the metadata of the assembly.