digitalmars.D.bugs - [Issue 3965] New: Multiple "static this()" can be a little error-prone
- d-bugmail puremagic.com (40/41) Mar 15 2010 http://d.puremagic.com/issues/show_bug.cgi?id=3965
- d-bugmail puremagic.com (12/12) Mar 15 2010 http://d.puremagic.com/issues/show_bug.cgi?id=3965
- d-bugmail puremagic.com (10/10) Mar 15 2010 http://d.puremagic.com/issues/show_bug.cgi?id=3965
- d-bugmail puremagic.com (16/16) Mar 16 2010 http://d.puremagic.com/issues/show_bug.cgi?id=3965
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: nobody puremagic.com
ReportedBy: bearophile_hugs eml.cc
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: -------
Mar 15 2010
http://d.puremagic.com/issues/show_bug.cgi?id=3965
Eldar Insafutdinov <e.insafutdinov gmail.com> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |e.insafutdinov gmail.com
11:56:15 PDT ---
If you followed the latest discussion on static constructors on the Newsgroup
you would see, that it's often required to mix in static constructors to
support library code. Your proposal renders it impossible.
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
Mar 15 2010
http://d.puremagic.com/issues/show_bug.cgi?id=3965
Trass3r <mrmocool gmx.de> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |mrmocool gmx.de
That's true, I also use that.
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
Mar 15 2010
http://d.puremagic.com/issues/show_bug.cgi?id=3965
Walter Bright <bugzilla digitalmars.com> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|NEW |RESOLVED
CC| |bugzilla digitalmars.com
Resolution| |WONTFIX
13:03:58 PDT ---
I believe this is a valuable feature for D. Sure, you can write convoluted code
with it, but so you can in general with any programming construct. Forcing it
all into one static constructor can also be confusing, because it takes away
locality of operations, which can cause its own confusion.
Won't implement.
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
Mar 16 2010









d-bugmail puremagic.com 