Fawzi Mohamed wrote:
On 2009-02-27 21:49:58 +0100, Fawzi Mohamed <fmoha...@mac.com> said:

On 2009-02-27 21:10:29 +0100, Walter Bright
<newshou...@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.

Reply via email to