QtD 0.1 is out!

Yigal Chripun yigal100 at gmail.com
Sat Feb 28 08:05:37 PST 2009


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.


More information about the Digitalmars-d-announce mailing list