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.pdfinitialization 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