Feature request - simpler constructors

[Bruno Medeiros]

kris wrote:
> Janice Caron wrote:
>> On 9/21/07, Walter Bright <newshound1 at digitalmars.com> wrote:
>>> Janice Caron wrote:
>>>> Please could we let
>>> I think it's a good idea, but I think using the function signature for
>>> it probably is not the best idea (as the function signature is for the
>>> interface, not the internals).
>>
>> Ah, well since that initial idea, lots of people have come up with
>> different alternatives, and the one suggested by Regan Heath is really
>> nice:
>>
>> class Point {
>>   int x;
>>   int y;
>>   int foo;  //not implicitly assigned any value
>>
>>   this(int x, int y, int bar):(x,y)  //bar is not assigned to anything
>>   {
>>     //super constructor calls go here
>>     //members are assigned here (_after_ calling super)
>>     //first line of user code goes here
>>     if (x > 5) {}  //refers to member 'x' not parameter 'x'
>>   }
>> }
>>
>> It's sort of similar to C++'s approach, but less typing and you don't
>> have to pick two different names for each variable, and if you wrote
>> the colon bit on the next line, it wouldn't be in the function
>> signature. (And if you didn't like the overuse of colon, you could
>> always use a keyword like you do for in, out and body).
>>
>> What I like about it is that you can do this:
>>
>>   this(int x, int y, int bar):(y,x)  //first assign y, then assign x
>>
>> in case there are side-effects to assignment order. Even better would
>> be to allow
>>
>>   this(int x, int y, int bar):(...)
>>
>> to be equivalent to
>>
>>   this(int x, int y, int bar):(x,y,bar)
>>
>> as between them, that set of possibilities seems to cover every need
>> suggested so far, including your need of not using the function
>> signature.
> 
> 
> Wow
> 
> All of that extra learning, indirection, and potential for confusion 
> just to avoid typing a relatively minuscule number of characters within 
> the ctor of a class:
> 
> # this.x = x, this.y = y;
> 
> I'm just knocked out. Really.
> 
> Here's a thought for everyone to consider. Please take a look at a large 
> and /practical/ body of code, written in D, by capable programmers, and 
> actually count the number of times this would even be applied? Now, take 
> that number and calculate a percentage against the size of the code body.
> 
> There's plenty of code in dsource to validate this notion against, 
> rather than speculating on a fictional basis.
> 
> FWIW: I'm quite familiar with at least two rather large bodies of code 
> there, and I can take a quick guess that neither body would apply 
> something like this even once, because there's simply no need for it. 
> Naturally, that doesn't cover every scenario or even a wide set of 
> tastes. However, it does indicate rather well that the notably few 
> "speshul" cases where this /might/ ever get used would likely cause 
> confusion to the reader or maintainer: *because it's not used often 
> enough to remember*
> 
> That spells "Feature Creep to The Max"
> 
> Just wow

I've often been running into this situation of creating constructors 
that assign their parameters to fields, but still I agree that it 
doesn't seem worth it to add new syntax just for this minor issue, at 
least not any of the syntax proposals presented here.
I can't argue any further other than re-state that I'm on the side that 
thinks the language should be kept _as simple as reasonable_. And this 
goes regardless of the fact that D has meta-programming capabilities 
that could allow implementing some feature like this outside of the 
language itself.

-- 
Bruno Medeiros - MSc in CS/E student
http://www.prowiki.org/wiki4d/wiki.cgi?BrunoMedeiros#D