static this sucks, we should deprecate it

Walter Bright newshound1 at digitalmars.com
Sun May 31 13:39:45 PDT 2009


Tim Matthews wrote:
> Walter Bright wrote:
>> It's unreliable because how do you specify the load order? And how 
>> does the user relate that to the source semantics?
> 
> grauzone suggested this earlier:
> static this {} //full dependencies (all import statements)
> static this : a, b {} //only dependent from module a and b
> static this : void {} //no dependencies at all

Such annotations tend to get seriously out of date and wrong as code 
evolves. For example, if A and B import each other:

-----------------------------
--- A ---
import B;
int foo() { ... }
static this()
{
    ...
}

--- B ---
import A;
import C;
int x;
static this : C()
{
     x = A.foo();
}

-------------------------------

Now, this may work just fine, until module A gets updated at some point 
in the future to depend on its static constructor. Then, B.x will get 
some unpredictable value, depending on the order of initialization.

So, in general, annotations in one module that specify what happens in 
another module are bad maintenance bugs waiting to happen.

The solution is relatively robust and straightforward. Create a third 
module, AB. Module A and module B both import AB. Put the static 
constructors for both A and B in module AB. The order of initialization 
problem is robustly solved, and all the interdependencies of 
initialization of A and B are explicitly laid out in AB.



More information about the Digitalmars-d mailing list