February 15, 2023
On 2/12/2023 6:44 AM, Puneet Goel wrote:
> I request the developers not to rush with deprecating Object.factory until a mechanism is developed to creak circular dependencies with modules.
Some methods given A imports B and B imports A:

1. Break up A and B so that the common part goes in C. The static constructor goes in C. I don't have the math to prove it, but I'm pretty sure that any A<=>B can be replaced with A<=C and B<=C. In fact, I think Go requires it (does not allow cyclical imports).

2. A bit kludgier way (but no refactoring needed) is for the C static constructor to call extern(C) void Actor(); and extern(C) void Bctor(); and have A provide a definition for Actor and B provide a definition for Bctor.

3. declare the constructors with pragma(crt_constructor). These are not order dependent, but one must take into account that they'll be run by the C startup code before druntime is initialized, meaning no GC will be available.
February 16, 2023

On Thursday, 16 February 2023 at 04:11:03 UTC, Walter Bright wrote:

>

Some methods given A imports B and B imports A:

  1. Break up A and B so that the common part goes in C. The static constructor goes in C. I don't have the math to prove it, but I'm pretty sure that any A<=>B can be replaced with A<=C and B<=C. In fact, I think Go requires it (does not allow cyclical imports).

You can always break import cycles by combining A and B into a new module C.

Then, as an extra step, sometimes some parts of C can be split out into separate modules A and B again. :)

1 2 3 4 5
Next ›   Last »