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