Re: Constructors?

Daniel Bonniot wrote:
>>> You should find the log of an irc discussion interesting: 
>>> http://confer09.condor-edv.com/nice@freenode/2004-09-18.html It
>>> starts at 14:47 (right column), at about the middle of the page.
>> 
>> That's interesting, I've also read the discussion about Constructor
>> Syntax in the Wiki.  While Java seems to have some holes in its 
>> constructor approach, I think C# has fixed these holes, or are
>> there also problems with C#?
> 
> I was not aware that C# had significant differences in this respect.
> Could you, or somebody else, summarize them, and investigate how the
> counter-example (present in the log above and on the wiki) goes in
> C#?

Given the class definitions:

class A {
   int x = 5;
   A() { getNum();};
   int getNum() {return x;}
}

class B extends A {
   int y = 6;
   B() {};
   int getNum() {return y;}
}

In Java, Instantiation of B is as follows:

initialize x = 5
call A()  // getNum returns 0, wrong!
initialize y = 6
call B()

However, In C#:

initialize x = 5 and y = 6
call A() // getNum returns 6, correct!
call B()

So, C# initializes everything first then calls the constructors.  Now C#
imposes a restriction that Java does not have such that initializers
cannot call methods, int y = getSomeVal(), since this would create a
situation in which uninitialized variables could be accessed.

Reference:  http://www.jot.fm/issues/issue_2002_11/article4
Look for section "5 CONSTRUCTORS"

> Note that we are not banning the use of custom constructors, so you
> can still use them if you really need specific initialization logic.
> We're just trying to make the common case as easy as possible (and in
> http://jroller.com/page/dbr/20040309#are_constructors_useless I
> found that about 60% of all constructors in Java programs could be
> avoided).

I agree.  I've written enough redundant syntax heavy constructors to 
really appreciate this feature.

> I see two things that could be improved to make Nice's approach
> easier to use:
> 
> 1) In the special case of a class without any fields, the call to 
> 'this()' should not be necessary. That would solve the problem you 
> initially reported.

Or classes without any non-initialized fields.

> 2) Instead of requiring a call to this(x: valueX, y: valueY), we
> could also allow constructor bodies that definitely assign a value to
> this.x and this.y, while still not allowing using the 'this' value.
> This would provide a more familiare syntax, with exactly the same
> safety properties.

I'm not sure I follow, so the following would be legal:

class A
{
   int x;
   new A()  // I know this syntax does not exist, YET! :)
   {
     x = 5;
   }
}

What would be illegal?



-------------------------------------------------------
This SF.net email is sponsored by: IT Product Guide on ITManagersJournal
Use IT products in your business? Tell us what you think of them. Give us
Your Opinions, Get Free ThinkGeek Gift Certificates! Click to find out more
http://productguide.itmanagersjournal.com/guidepromo.tmpl