http://d.puremagic.com/issues/show_bug.cgi?id=3965
Summary: Multiple "static this()" can be a little error-prone
Product: D
Version: 2.041
Platform: All
OS/Version: All
Status: NEW
Severity: enhancement
Priority: P2
Component: DMD
AssignedTo: nob...@puremagic.com
ReportedBy: bearophile_h...@eml.cc
--- Comment #0 from bearophile_h...@eml.cc 2010-03-15 08:58:51 PDT ---
This is inspired by the "Initialization diffusion" part of article "Coping with
Java Programming Stress":
http://www.cs.colostate.edu/~rta/publications/Computer00.pdf
>initialization code is distributed between constructors and initialization
>blocks, which can be distributed throughout a class. Thus, to understand the
>full instance initialization and construction process, you must understand the
>semantics of constructors and instance initialization blocks. This means
>scanning an entire class definition looking for instance initializers,
>analyzing the semantics of each initializer and its order of execution, and
>then analyzing the class construction methods' semantics. This process is
>tedious and error-prone when you have many instance initializer blocks.<
This is a D example:
int a, b;
static this() { a = 10; }
class Foo {
static this() { Foo.x = 10; }
static int x, y;
static this() { Foo.y = 20; }
}
static this() { b = 10; }
void main() {}
To avoid that small problem D can allow only one "static this()" for each class
(and maybe allow only one global static this in a module. But in my opinion
estricting only one module static constructor is less important than
restricting to one the static costructor of classes). So only this is allowed:
int a, b;
static this() { a = 10; b = 10; }
class Foo {
static this() { Foo.x = 10; Foo.y = 20; }
static int x, y;
}
void main() {}
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
