[Issue 3878] Arguments and members with the same name (page 2)

March 21, 2011
[Issue 3878] Arguments and members with the same name
Posted by bearophile_hugs@eml.cc
in reply to bearophile_hugs@eml.cc
Permalink
bearophile_hugs@eml.cc
Posted in reply to bearophile_hugs@eml.cc
Permalink
http://d.puremagic.com/issues/show_bug.cgi?id=3878



--- Comment #10 from bearophile_hugs@eml.cc 2011-03-21 15:01:43 PDT ---
(In reply to comment #9)

A simpler solution are classes with automatic constructors:

class Foo {
  string x;
  int y = 1;
}
void main() {
  Foo f1 = new Foo(); // Good
  Foo f2 = new Foo("hello"); // Good
  Foo f3 = new Foo("hello", 10); // Good
}


Some comments from a discussion thread:

-----------------

Daniel Gibson:

>> A simpler solution are classes with automatic constructors:
>>
>> class Foo {
>>    string x;
>>    int y = 1;
>> }
>> void main() {
>>    Foo f1 = new Foo(); // Good
>>    Foo f2 = new Foo("hello"); // Good
>>    Foo f3 = new Foo("hello", 10); // Good
>> }
>>
>>
>> What kind of problems are caused by this? :-)
> 
> You'd have to know the order in that the members are defined in the
> class (and you may not change the order).
> Just imagine
> class Foo {
>    int bla;
>    int baz;
> }
> 
> new Foo(42, 3); // what is bla, what is baz?
> 
> and then you decide "uh I'd prefer to have my class members ordered alphabetically" and *bamm* all you code silently breaks.
> 
> having a this(this.bla, this.baz) {} would clearly document which argument in the constructor belongs to which class member and the class members ordering wouldn't matter.

-----------------

Don:

> I agree. But unfortunately, the idea is a relatively complicated feature
> with a lot of special cases. For example, this(this.bla, this.bla){}
> and what if the class contains a union and you set multiple members of it?
> The whole thing is actually quite messy. It's not _terrible_, but it's
> far from trivial, and it's more complicated than some far more powerful
> and useful language features.

-----------------

KennyTM~:

>> I agree. But unfortunately, the idea is a relatively complicated feature with a lot of special cases. For example, this(this.bla, this.bla){}
> 
> 'int f(int x, int x) {}' is a syntax error. So should 'this(this.x,
> this.x){}'.

-----------------

Daniel Gibson:

>> 'int f(int x, int x) {}' is a syntax error. So should 'this(this.x, this.x){}'.
> 
> and probably this(this.x, x){}

-----------------

Don:

> It's not that it's complicated, it's that for structs, the ordering of their members is part of the public interface. For classes, the members are not public.

>> and probably this(this.x, x){}
> 
> Exactly. That's why it's messier than it first appears.
> My point is -- people tend to think things like this are trivial
> features because they are not very powerful; and conversely, they think
> that powerful features must be complicated. But that's really
> misleading. 'pure', for example, is roughly the same level of
> implementation complexity as this feature.

-----------------

KennyTM~:

>> and probably this(this.x, x){}
> 
> Yes. This is handled by the AST transform (lowering) too.
> 
>      this(this.x, int x) {
>        statements;
>      }
> 
> becomes
> 
>      this(typeof(this.x) x, int x) {
>        this.x = x;
>        statements;
>      }
> 
> which will complain
> 
>      Error: constructor x.Foo.this parameter this.x is already defined
> 
> as expected.

-----------------

Overall I think the syntax this(this.x){} causes less troubles (class field keep being private, their order doesn't need to become public), while avoiding the bug that's the main topic of this enhancement request.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
Forums
