www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - inheriting constructos

reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
Walter and I just discussed the matter of inheriting constructors. Our 
thought on the issue:

a) If a class doesn't define any constructors and adds no fields, 
inherit constructors. Example:

class MyException : Exception {}

b) If a class defines at least one constructor, do not inherit constructors.

c) If a class doesn't define any constructors but does add at least a 
non-static field -> undecided.

What do you think?


Andrei
Nov 29 2009
next sibling parent reply bearophile <bearophileHUGS lycos.com> writes:
Andrei Alexandrescu:
 c) If a class doesn't define any constructors but does add at least a 
 non-static field -> undecided.
Does 'undecided' mean 'compile-time error'?" Bye, bearophile
Nov 29 2009
next sibling parent reply "Denis Koroskin" <2korden gmail.com> writes:
On Mon, 30 Nov 2009 02:20:40 +0300, bearophile <bearophileHUGS lycos.com=
  =
wrote:
 Andrei Alexandrescu:
 c) If a class doesn't define any constructors but does add at least a=
 non-static field -> undecided.
Does 'undecided' mean 'compile-time error'?" Bye, bearophile
I think it means they are not decided whether it should inherit = constructors. Back on topic, I do think inheriting constructors is a good idea, even i= n = presence of additional fields (why not?) I also think constructor inheritance could be implemented without any = changes to the language the following way: this(Args...)(Args args) if (__traits(compiles, super(args))) { super(args); // initialize additional fields, if any present // and/or do some post-construction logic } Why create new rules? :) The trivial way could be even simplified like this: // just a basic idea template InheritCtors() { this(Args...)(Args args) if (__traits(compiles, super(args))) { super(args); static assert (this.tupleof =3D=3D super.typleof); // check tha= t no = additional members present } } class Foo { /* a few different ctors */ } class Bar : Foo { mixin InheritCtors(); // Voil=C3=A0! }
Nov 29 2009
parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
Denis Koroskin wrote:
 On Mon, 30 Nov 2009 02:20:40 +0300, bearophile 
 <bearophileHUGS lycos.com> wrote:
 
 Andrei Alexandrescu:
 c) If a class doesn't define any constructors but does add at least a
 non-static field -> undecided.
Does 'undecided' mean 'compile-time error'?" Bye, bearophile
I think it means they are not decided whether it should inherit constructors. Back on topic, I do think inheriting constructors is a good idea, even in presence of additional fields (why not?) I also think constructor inheritance could be implemented without any changes to the language the following way: this(Args...)(Args args) if (__traits(compiles, super(args))) { super(args); // initialize additional fields, if any present // and/or do some post-construction logic } Why create new rules? :)
Alas, that doesn't work because of ref and out arguments. I actually think it's a language bug that it's impossible to implement perfect forwarding. Andrei
Nov 29 2009
parent reply "Denis Koroskin" <2korden gmail.com> writes:
On Mon, 30 Nov 2009 03:18:27 +0300, Andrei Alexandrescu  
<SeeWebsiteForEmail erdani.org> wrote:

 Denis Koroskin wrote:
 On Mon, 30 Nov 2009 02:20:40 +0300, bearophile  
 <bearophileHUGS lycos.com> wrote:

 Andrei Alexandrescu:
 c) If a class doesn't define any constructors but does add at least a
 non-static field -> undecided.
Does 'undecided' mean 'compile-time error'?" Bye, bearophile
I think it means they are not decided whether it should inherit constructors. Back on topic, I do think inheriting constructors is a good idea, even in presence of additional fields (why not?) I also think constructor inheritance could be implemented without any changes to the language the following way: this(Args...)(Args args) if (__traits(compiles, super(args))) { super(args); // initialize additional fields, if any present // and/or do some post-construction logic } Why create new rules? :)
Alas, that doesn't work because of ref and out arguments. I actually think it's a language bug that it's impossible to implement perfect forwarding. Andrei
Well, intuitively it should be implemented this way: class Foo { /* a few different ctors */ } class Bar : Foo { alias super.this this; // the same way you do // "alias super.someMethod someMethod;" to add someMethod into current scope } Unfortunately, this conflicts with alias this feature. If we could rename constructors from "this" to "ctor", we could use it with no ambiguity: class Bar : Foo { alias super.ctor ctor; ctor(Other other) { // ... shoudn't conflict with existing ctors (or should it?) } } This would also help getting rid an ugly "__ctor" identifier which is used as placement new: void[] mem = allocate!(T); // old style T.__ctor(mem); // new style T.ctor(mem);
Nov 29 2009
next sibling parent bearophile <bearophileHUGS lycos.com> writes:
Denis Koroskin:
 Unfortunately, this conflicts with alias this feature. If we could rename  
 constructors from "this" to "ctor", we could use it with no ambiguity:
That's another keyword, I think. When I read that word it reminds me this word: http://www.legrog.org/visuels/couvertures/71.jpg Sorry, bye, bearophile
Nov 29 2009
prev sibling parent davidl <davidl nospam.org> writes:
在 Mon, 30 Nov 2009 09:35:17 +0800,Denis Koroskin <2korden gmail.com>  
写道:

 On Mon, 30 Nov 2009 03:18:27 +0300, Andrei Alexandrescu  
 <SeeWebsiteForEmail erdani.org> wrote:

 Denis Koroskin wrote:
 On Mon, 30 Nov 2009 02:20:40 +0300, bearophile  
 <bearophileHUGS lycos.com> wrote:

 Andrei Alexandrescu:
 c) If a class doesn't define any constructors but does add at least a
 non-static field -> undecided.
Does 'undecided' mean 'compile-time error'?" Bye, bearophile
I think it means they are not decided whether it should inherit constructors. Back on topic, I do think inheriting constructors is a good idea, even in presence of additional fields (why not?) I also think constructor inheritance could be implemented without any changes to the language the following way: this(Args...)(Args args) if (__traits(compiles, super(args))) { super(args); // initialize additional fields, if any present // and/or do some post-construction logic } Why create new rules? :)
Alas, that doesn't work because of ref and out arguments. I actually think it's a language bug that it's impossible to implement perfect forwarding. Andrei
Well, intuitively it should be implemented this way: class Foo { /* a few different ctors */ } class Bar : Foo { alias super.this this; // the same way you do // "alias super.someMethod someMethod;" to add someMethod into current scope } Unfortunately, this conflicts with alias this feature. If we could rename constructors from "this" to "ctor", we could use it with no ambiguity:
I think opDispatch should be able to simulate the current alias this feature. And current alias this should be something work like the example you provided.
 class Bar : Foo
 {
      alias super.ctor ctor;

      ctor(Other other)
      {
         // ... shoudn't conflict with existing ctors (or should it?)
      }
 }

 This would also help getting rid an ugly "__ctor" identifier which is  
 used as placement new:

 void[] mem = allocate!(T);

 // old style
 T.__ctor(mem);

 // new style
 T.ctor(mem);
-- 使用 Opera 革命性的电子邮件客户程序: http://www.opera.com/mail/
Nov 30 2009
prev sibling parent Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
bearophile wrote:
 Andrei Alexandrescu:
 c) If a class doesn't define any constructors but does add at least a 
 non-static field -> undecided.
Does 'undecided' mean 'compile-time error'?"
We're undecided. Andrei
Nov 29 2009
prev sibling next sibling parent "Nick Sabalausky" <a a.a> writes:
"Andrei Alexandrescu" <SeeWebsiteForEmail erdani.org> wrote in message 
news:heuuk9$1nfq$1 digitalmars.com...
 Walter and I just discussed the matter of inheriting constructors. Our 
 thought on the issue:

 a) If a class doesn't define any constructors and adds no fields, inherit 
 constructors. Example:

 class MyException : Exception {}

 b) If a class defines at least one constructor, do not inherit 
 constructors.

 c) If a class doesn't define any constructors but does add at least a 
 non-static field -> undecided.

 What do you think?


 Andrei
I could swear that I've recently been using a language that does exactly that (with 'c' falling in the same category as 'a'), and have been very happy with how it handles that, but I can't remember what language it was for it (with 'c' acting like 'a').
Nov 29 2009
prev sibling next sibling parent reply Don <nospam nospam.com> writes:
Andrei Alexandrescu wrote:
 Walter and I just discussed the matter of inheriting constructors. Our 
 thought on the issue:
 
 a) If a class doesn't define any constructors and adds no fields, 
 inherit constructors. Example:
 
 class MyException : Exception {}
 
 b) If a class defines at least one constructor, do not inherit 
 constructors.
 
 c) If a class doesn't define any constructors but does add at least a 
 non-static field -> undecided.
 
 What do you think?
 
 Andrei
I would add: "and the class does not define a class invariant". A constructor exists to establish the class invariant (even if that invariant is implicit). For (a), the old invariant will still be satisfied. In the case (c) there is a chance that the invariant will not be appropriate. In (c), I suggest that it is valid to inherit constructors if and only if the new class is a simple aggregate of the old class, together with the new members (which may have invariants of their own). If there's no constructor and no invariant, then either it's a simple aggregate, or it's a bug.
Nov 30 2009
parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
Don wrote:
 Andrei Alexandrescu wrote:
 Walter and I just discussed the matter of inheriting constructors. Our 
 thought on the issue:

 a) If a class doesn't define any constructors and adds no fields, 
 inherit constructors. Example:

 class MyException : Exception {}

 b) If a class defines at least one constructor, do not inherit 
 constructors.

 c) If a class doesn't define any constructors but does add at least a 
 non-static field -> undecided.

 What do you think?

 Andrei
I would add: "and the class does not define a class invariant". A constructor exists to establish the class invariant (even if that invariant is implicit). For (a), the old invariant will still be satisfied. In the case (c) there is a chance that the invariant will not be appropriate. In (c), I suggest that it is valid to inherit constructors if and only if the new class is a simple aggregate of the old class, together with the new members (which may have invariants of their own). If there's no constructor and no invariant, then either it's a simple aggregate, or it's a bug.
Good point. I do think of classes that add fields that don't mess up the invariant though: class MyException : Exception { private int sysCode; invariant() { assert(sysCode < 100); } } If default initialization of the field puts it in a state that respects the invariant, there isn't a problem. Andrei
Nov 30 2009
next sibling parent Don <nospam nospam.com> writes:
Andrei Alexandrescu wrote:
 Don wrote:
 Andrei Alexandrescu wrote:
 Walter and I just discussed the matter of inheriting constructors. 
 Our thought on the issue:

 a) If a class doesn't define any constructors and adds no fields, 
 inherit constructors. Example:

 class MyException : Exception {}

 b) If a class defines at least one constructor, do not inherit 
 constructors.

 c) If a class doesn't define any constructors but does add at least a 
 non-static field -> undecided.

 What do you think?

 Andrei
I would add: "and the class does not define a class invariant". A constructor exists to establish the class invariant (even if that invariant is implicit). For (a), the old invariant will still be satisfied. In the case (c) there is a chance that the invariant will not be appropriate. In (c), I suggest that it is valid to inherit constructors if and only if the new class is a simple aggregate of the old class, together with the new members (which may have invariants of their own). If there's no constructor and no invariant, then either it's a simple aggregate, or it's a bug.
Good point. I do think of classes that add fields that don't mess up the invariant though: class MyException : Exception { private int sysCode; invariant() { assert(sysCode < 100); } } If default initialization of the field puts it in a state that respects the invariant, there isn't a problem.
Oh, that's an interesting one. If default initialization doesn't respect the invariant, the invariant is likely to catch it on first use anyway. So requiring no invariant probably wouldn't catch many bugs. The fact that D does default initialization makes this whole issue much less perilous than in C++. Returning to the original question: Right now, constructors are inherited if they have no parameters. It's hard to see why the no-parameter case should be treated differently.
Nov 30 2009
prev sibling parent Michel Fortin <michel.fortin michelf.com> writes:
On 2009-11-30 10:30:11 -0500, Andrei Alexandrescu 
<SeeWebsiteForEmail erdani.org> said:

 class MyException : Exception {
      private int sysCode;
      invariant() { assert(sysCode < 100); }
 }
 
 If default initialization of the field puts it in a state that respects 
 the invariant, there isn't a problem.
I think this simply shows that if super's constructor is inherited, once the object is constructed invariant() should be called (and not super's invariant, the one of the object actually constructed). If you do that you'll catch any field not respecting the invariant right after construction. -- Michel Fortin michel.fortin michelf.com http://michelf.com/
Nov 30 2009
prev sibling next sibling parent reply Ary Borenszweig <ary esperanto.org.ar> writes:
Andrei Alexandrescu wrote:
 Walter and I just discussed the matter of inheriting constructors. Our 
 thought on the issue:
 
 a) If a class doesn't define any constructors and adds no fields, 
 inherit constructors. Example:
 
 class MyException : Exception {}
 
 b) If a class defines at least one constructor, do not inherit 
 constructors.
 
 c) If a class doesn't define any constructors but does add at least a 
 non-static field -> undecided.
 
 What do you think?
I like this. I think c should be a compile-time error. Here's another use for annotations, in case you define new fields but still want to inherit the constructors: InheritConstructors class Foo : Bar { }
Nov 30 2009
parent reply "Nick Sabalausky" <a a.a> writes:
"Ary Borenszweig" <ary esperanto.org.ar> wrote in message 
news:hf03ps$lk2$1 digitalmars.com...
 Andrei Alexandrescu wrote:
 Walter and I just discussed the matter of inheriting constructors. Our 
 thought on the issue:

 a) If a class doesn't define any constructors and adds no fields, inherit 
 constructors. Example:

 class MyException : Exception {}

 b) If a class defines at least one constructor, do not inherit 
 constructors.

 c) If a class doesn't define any constructors but does add at least a 
 non-static field -> undecided.

 What do you think?
 I think c should be a compile-time error.
Why? (Not to be contentious.)
Nov 30 2009
parent reply Ary Borenszweig <ary esperanto.org.ar> writes:
Nick Sabalausky wrote:
 "Ary Borenszweig" <ary esperanto.org.ar> wrote in message 
 news:hf03ps$lk2$1 digitalmars.com...
 Andrei Alexandrescu wrote:
 Walter and I just discussed the matter of inheriting constructors. Our 
 thought on the issue:

 a) If a class doesn't define any constructors and adds no fields, inherit 
 constructors. Example:

 class MyException : Exception {}

 b) If a class defines at least one constructor, do not inherit 
 constructors.

 c) If a class doesn't define any constructors but does add at least a 
 non-static field -> undecided.

 What do you think?
 I think c should be a compile-time error.
Why? (Not to be contentious.)
At first I thought you might want to add fields to a subclass for logging, or caching, stuff like that, while still wanting to inherit the constructors. Then I checked some code for a project I wrote in Java and always when the subclass had new fields it defined a different constructor, and the logging fields were static. So I think that most of the time you'd want to inherit the constructors when you don't define new fields.
Nov 30 2009
next sibling parent Sean Kelly <sean invisibleduck.org> writes:
Ary Borenszweig Wrote:

 Nick Sabalausky wrote:
 "Ary Borenszweig" <ary esperanto.org.ar> wrote in message 
 news:hf03ps$lk2$1 digitalmars.com...
 Andrei Alexandrescu wrote:
 Walter and I just discussed the matter of inheriting constructors. Our 
 thought on the issue:

 a) If a class doesn't define any constructors and adds no fields, inherit 
 constructors. Example:

 class MyException : Exception {}

 b) If a class defines at least one constructor, do not inherit 
 constructors.

 c) If a class doesn't define any constructors but does add at least a 
 non-static field -> undecided.

 What do you think?
 I think c should be a compile-time error.
Why? (Not to be contentious.)
At first I thought you might want to add fields to a subclass for logging, or caching, stuff like that, while still wanting to inherit the constructors. Then I checked some code for a project I wrote in Java and always when the subclass had new fields it defined a different constructor, and the logging fields were static. So I think that most of the time you'd want to inherit the constructors when you don't define new fields.
Since class member data is default initialized, I'm not sure I agree. For example, let's say I want to modify a string class to add a search feature, and I want it to cache the prior result for performance reasons. There's no need to ctor-initialize the result field, only to make sure it's null at the start.
Nov 30 2009
prev sibling parent reply Michel Fortin <michel.fortin michelf.com> writes:
On 2009-11-30 18:45:38 -0500, Ary Borenszweig <ary esperanto.org.ar> said:

 Nick Sabalausky wrote:
 "Ary Borenszweig" <ary esperanto.org.ar> wrote in message 
 news:hf03ps$lk2$1 digitalmars.com...
 Andrei Alexandrescu wrote:
 c) If a class doesn't define any constructors but does add at least a 
 non-static field -> undecided.
 
 What do you think?
I think c should be a compile-time error.
Why? (Not to be contentious.)
At first I thought you might want to add fields to a subclass for logging, or caching, stuff like that, while still wanting to inherit the constructors. Then I checked some code for a project I wrote in Java and always when the subclass had new fields it defined a different constructor, and the logging fields were static. So I think that most of the time you'd want to inherit the constructors when you don't define new fields.
But then how do you go from "most of the time you want to inherit the constructor" to "it should be a compile-time error"? Do you believe people would forget to add the constructor when it's needed, leading into hard to find bugs? I often create subclasses in Objective-C where I just override one method so I can hook a custom behavior somewhere, and this often requires a new field. But most of the time the default value given to that field at construction (null or zero) is fine so I don't bother needlessly rewriting constructors. The question then is: should I be forced to add a constructor when I don't need one because you want the compiler to remind you you should when you add a field? I'm not sure which side wins at this question. And in this case I'd go for the most simple rules: don't bother about added fields. -- Michel Fortin michel.fortin michelf.com http://michelf.com/
Dec 01 2009
parent Ary Borenszweig <ary esperanto.org.ar> writes:
Michel Fortin wrote:
 On 2009-11-30 18:45:38 -0500, Ary Borenszweig <ary esperanto.org.ar> said:
 
 Nick Sabalausky wrote:
 "Ary Borenszweig" <ary esperanto.org.ar> wrote in message 
 news:hf03ps$lk2$1 digitalmars.com...
 Andrei Alexandrescu wrote:
 c) If a class doesn't define any constructors but does add at least 
 a non-static field -> undecided.

 What do you think?
I think c should be a compile-time error.
Why? (Not to be contentious.)
At first I thought you might want to add fields to a subclass for logging, or caching, stuff like that, while still wanting to inherit the constructors. Then I checked some code for a project I wrote in Java and always when the subclass had new fields it defined a different constructor, and the logging fields were static. So I think that most of the time you'd want to inherit the constructors when you don't define new fields.
But then how do you go from "most of the time you want to inherit the constructor" to "it should be a compile-time error"? Do you believe people would forget to add the constructor when it's needed, leading into hard to find bugs? I often create subclasses in Objective-C where I just override one method so I can hook a custom behavior somewhere, and this often requires a new field. But most of the time the default value given to that field at construction (null or zero) is fine so I don't bother needlessly rewriting constructors. The question then is: should I be forced to add a constructor when I don't need one because you want the compiler to remind you you should when you add a field? I'm not sure which side wins at this question. And in this case I'd go for the most simple rules: don't bother about added fields.
I think that unit testing is one of the most important things when programming, so letting the compiler always inherit the constructors for you is ok (if you don't define at least one constructor) because if you forgot to initialize a field you'll catch the bug sooner or later in a unit test or (hopefully not!) in runtime.
Dec 02 2009
prev sibling next sibling parent reply Michel Fortin <michel.fortin michelf.com> writes:
On 2009-11-29 18:03:40 -0500, Andrei Alexandrescu 
<SeeWebsiteForEmail erdani.org> said:

 Walter and I just discussed the matter of inheriting constructors. Our 
 thought on the issue:
 
 a) If a class doesn't define any constructors and adds no fields, 
 inherit constructors. Example:
 
 class MyException : Exception {}
 
 b) If a class defines at least one constructor, do not inherit constructors.
 
 c) If a class doesn't define any constructors but does add at least a 
 non-static field -> undecided.
 
 What do you think?
Objective-C has 'a' and 'c' acting like 'a'. There's no 'b' though, and this is a small annoyance, as "constructors" in Objective-C are just normal methods with a name that starts with "init". Personally, I'd say adding a field to a class shouldn't affect its constructor. If you need to initialize the field at object's construction, then you add a constructor. But otherwise, if you don't need to initialize it at construction (which happens fairly often when fields are zeroed anyway), then you can certainly inherit super's constructors. In fact, I find it hard to see a justification for making adding a field break constructor inheritance. My experience with Objective-C tells me that 'c' acting like 'a' wouldn't be a problem at all because D, just like Objective-C, initializes all fields to a default value anyway. You only need a constructor when you want a non-default value in a field. -- Michel Fortin michel.fortin michelf.com http://michelf.com/
Nov 30 2009
parent Sean Kelly <sean invisibleduck.org> writes:
Michel Fortin Wrote:

 On 2009-11-29 18:03:40 -0500, Andrei Alexandrescu 
 <SeeWebsiteForEmail erdani.org> said:
 
 Walter and I just discussed the matter of inheriting constructors. Our 
 thought on the issue:
 
 a) If a class doesn't define any constructors and adds no fields, 
 inherit constructors. Example:
 
 class MyException : Exception {}
 
 b) If a class defines at least one constructor, do not inherit constructors.
 
 c) If a class doesn't define any constructors but does add at least a 
 non-static field -> undecided.
 
 What do you think?
Objective-C has 'a' and 'c' acting like 'a'. There's no 'b' though, and this is a small annoyance, as "constructors" in Objective-C are just normal methods with a name that starts with "init". Personally, I'd say adding a field to a class shouldn't affect its constructor. If you need to initialize the field at object's construction, then you add a constructor. But otherwise, if you don't need to initialize it at construction (which happens fairly often when fields are zeroed anyway), then you can certainly inherit super's constructors. In fact, I find it hard to see a justification for making adding a field break constructor inheritance. My experience with Objective-C tells me that 'c' acting like 'a' wouldn't be a problem at all because D, just like Objective-C, initializes all fields to a default value anyway. You only need a constructor when you want a non-default value in a field.
I would hope that explicit out-of-ctor initialization would be allowed too: class A : B { // inherit B's ctors int x = 5; } Are there any instances where that calls an invisible ctor instead of just altering the init blob?
Nov 30 2009
prev sibling next sibling parent Sean Kelly <sean invisibleduck.org> writes:
Andrei Alexandrescu Wrote:

 Walter and I just discussed the matter of inheriting constructors. Our 
 thought on the issue:
 
 a) If a class doesn't define any constructors and adds no fields, 
 inherit constructors. Example:
 
 class MyException : Exception {}
 
 b) If a class defines at least one constructor, do not inherit constructors.
 
 c) If a class doesn't define any constructors but does add at least a 
 non-static field -> undecided.
 
 What do you think?
I thought it was a great idea 2 years ago: http://www.digitalmars.com/d/archives/digitalmars/D/Inheriting_constructors_54088.html Haven't changed my mind since then :-)
Nov 30 2009
prev sibling parent reply Lionello Lunesu <lio lunesu.remove.com> writes:
Perhaps reusing a constructor of an inherited class should be easier. 
Something like "alias this"? But how to refer to specific ctor overloads?

L.

On 30-11-2009 1:03, Andrei Alexandrescu wrote:
 Walter and I just discussed the matter of inheriting constructors. Our
 thought on the issue:

 a) If a class doesn't define any constructors and adds no fields,
 inherit constructors. Example:

 class MyException : Exception {}

 b) If a class defines at least one constructor, do not inherit
 constructors.

 c) If a class doesn't define any constructors but does add at least a
 non-static field -> undecided.

 What do you think?


 Andrei
Dec 04 2009
parent Michael Rynn <michaelrynn optusnet.com.au> writes:
On Fri, 04 Dec 2009 10:05:16 +0200, Lionello Lunesu wrote:

 Perhaps reusing a constructor of an inherited class should be easier.
 Something like "alias this"? But how to refer to specific ctor
 overloads?
 
 L.
 
 On 30-11-2009 1:03, Andrei Alexandrescu wrote:
 Walter and I just discussed the matter of inheriting constructors. Our
 thought on the issue:

 a) If a class doesn't define any constructors and adds no fields,
 inherit constructors. Example:

 class MyException : Exception {}

 b) If a class defines at least one constructor, do not inherit
 constructors.

 c) If a class doesn't define any constructors but does add at least a
 non-static field -> undecided.

 What do you think?


 Andrei
I do not want the compiler to decide this for me. I do have cases where the constructor has to be repeated for each generation of child classes for the values that will eventually set for some parent class. You can object there must be something wrong with the design here. But would it not be possible to indicate in the child class that the constructor is the same as the parent. class parent { this(t1 everybody, t2 gets, t3 it){} } class child : parent { this(t1 everybody, t2 gets, t3 it) { super(everybody, gets, it); } } Would like if the compiler could optimise the call to child.this away. or just shorten it indicate the constructor is the same (without using another key word ) Such a shortening, using a '.' or ':' would be transitive. class child : parent { //calls parent.this this.super(t1 everybody, t2 gets, t3 it); } class gchild : child { //calls parent.this this.super(t1 everybody, t2 gets, t3 it); }
Mar 07 2010