Cyclic dependencies vs static constructors

[Steven Schveighoffer]

On 12/19/17 12:43 PM, Jean-Louis Leroy wrote:

> As the program grows bigger, I want to split it into several modules, 
> e.g. one per class or one per hierarchy. Now I have cyclic dependencies 
> between modules because role.d must 'import company' and 'company.d' 
> must 'import role'.
> 
> It seems that at this point I have forgone a language feature: static 
> constructors. They may be needed if I want to implement e.g. a global 
> registry in Role and Company that tracks all the instances of the 
> classes in their respective hierarchy.

Yes, static constructor dependencies are a very crude mechanism. It 
assumes if you make an import, anything from that import could possibly 
be used in the static ctor, and anything in that module could depend on 
static ctors in that module.

There have been several ideas on how to make them more manageable. But 
the truth is, it's really hard to come up with ways to detect whether 
static ctors *really* depend on each other.

What you may consider is to implement the registration outside the 
module itself. That is, have a helper module that imports the class 
defining module, which isn't imported from anywhere. One issue there is 
that the compiler/linker may trim out that module!

It really is a bad mess. I don't know of a good way to solve it, without 
coming up with an attribute scheme to manually identify the dependencies.

-Steve