www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.bugs - [Issue 3965] New: Multiple "static this()" can be a little error-prone

reply d-bugmail puremagic.com writes:
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
next sibling parent d-bugmail puremagic.com writes:
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
prev sibling next sibling parent d-bugmail puremagic.com writes:
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
prev sibling parent d-bugmail puremagic.com writes:
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