Proposal: static ctor priority
BCS
ao at pathlink.com
Thu Jun 21 12:55:06 PDT 2007
Reply to Daniel,
> The other night, I was writing code for a game prototype when I ran
> into the old cyclic module dependency problem.
>
> Basically, the issue was that engine imports window, and window needs
> to talk to the engine. Both have loggers for writing out debug
> information, which are (ideally) created in static ctors.
>
> So, even though there is no *actual* dependency between the ctors,
> they still fail to compile. Previously, people have suggested flow
> analysis to solve this, but flow analysis would be a lot of work.
>
> Therefore, my proposal is to introduce a new pragma to resolve this.
> Example:
>
> module a;
> import b;
> pragma(priority, 2)
> static this()
> {
> // Do stuff
> }
> module b;
> import a;
> // defaults to priority 1.
> static this()
> {
> // Do other stuff
> }
> (NB: modules are initialised from higher priority (int.max) to lowest
> (int.min))
>
> This would allow developers to manually break these cycles by
> specifying
> the relative order they should be initialised in. For bonus points,
> make this possible:
> module a;
> import b;
> pragma(priority, b+1)
> static this() {
> ...
> This should be much easier to implement than flow analysis, whilst
> still solving the problem.
>
> Comments?
>
> -- Daniel
>
I'd reather it be done with explicet flow ordering
module foo;
import bar, baz;
this(baz){writef("foo\n");}
module bar;
import foo, baz;
this(foo, baz){writef("bar\n");}
module baz;
import foo, ;
this(null){writef("baz\n");}
output:
baz
foo
bar
Any cycle are explicit errors (at compile time if it can be detected then),
"null" means no dependencies, "()" means everything imported and a list means
only that list.
Actually I'd rather it be even more flexible than that but I can't think
of a clean way to code what I want.
More information about the Digitalmars-d
mailing list