Re: Re: Constructors?
Daniel Bonniot <[email protected]> Thu, 07 Oct 2004 12:29:14 +0200
| Newsgroups | gmane.comp.lang.nice.general |
|---|---|
| Message-ID | <[email protected]> |
>> 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#? > It's probably the case I've got too much Java/C++ on my brain, so I'm > slow to embrace the new approach. I'm so use to accessing instance > variables in constructors that it's habit now. I would hate to see in > the initializer conditional logic based on the way an instance is being > constructed. However, I don't know if the would really be a problem in > practice. I think I'll go take a look at past java code I've written > and examine the non trivial constructors I've written and investigate > the application of a Nice solution. Please report here what you found, it should be interesting. 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 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. 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. Note that feature 1) can actually be seen as a (simpler) special case of 2). If somebody feels like getting involved in developing the language, these could be good features to start with. Cheers, Daniel ------------------------------------------------------- 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