www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.learn - What's the technical reason that class ctors aren't virtual?

reply Andrej Mitrovic <andrej.mitrovich gmail.com> writes:
class Foo
{
    this(int x, int y) { }
}

class Bar : Foo
{
}

Bar has to define its own ctor even if it only forwards the call to
the super() ctor, e.g.:

class Bar : Foo
{
    this(int x, int y) { super(x, y); }
}

But I'm curious why this works this way. If I have a large inheritance
tree of classes and I want to change the base class ctor (say I want
to add another int as a parameter), I'll have to change all the ctors
in the subclasses as well.

Isn't that counterproductive?
Aug 24 2011
next sibling parent reply Ali =?iso-8859-1?q?=C7ehreli?= <acehreli yahoo.com> writes:
On Wed, 24 Aug 2011 16:59:46 +0200, Andrej Mitrovic wrote:

 class Foo
 {
     this(int x, int y) { }
 }
 
 class Bar : Foo
 {
 }
 
 Bar has to define its own ctor even if it only forwards the call to the
 super() ctor, e.g.:
 
 class Bar : Foo
 {
     this(int x, int y) { super(x, y); }
 }
That's because it is Bar that constructs its Foo part. The user constructs a Bar and must provide only what Bar needs, potentially nothing: class Bar : Foo { this() { super(42, 43); }
 But I'm curious why this works this way.
Another reason would be function hijacking: Subtle changes in types of contsructor parameters might bypass derived constructors just becaues they now match better to the super's.
 If I have a large inheritance
 tree of classes and I want to change the base class ctor (say I want to
 add another int as a parameter), I'll have to change all the ctors in
 the subclasses as well.
 
 Isn't that counterproductive?
Sounds like it but is necessary: Which of the constructors of the derived constructors should the compiler call after calling super's matching one? If it didn't, the derived parts would be left unconstructed. Ali
Aug 24 2011
parent Ary Manzana <ary esperanto.org.ar> writes:
On 8/24/11 12:27 PM, Ali Çehreli wrote:
 On Wed, 24 Aug 2011 16:59:46 +0200, Andrej Mitrovic wrote:

 class Foo
 {
      this(int x, int y) { }
 }

 class Bar : Foo
 {
 }

 Bar has to define its own ctor even if it only forwards the call to the
 super() ctor, e.g.:

 class Bar : Foo
 {
      this(int x, int y) { super(x, y); }
 }
That's because it is Bar that constructs its Foo part. The user constructs a Bar and must provide only what Bar needs, potentially nothing: class Bar : Foo { this() { super(42, 43); }
 But I'm curious why this works this way.
Another reason would be function hijacking: Subtle changes in types of contsructor parameters might bypass derived constructors just becaues they now match better to the super's.
 If I have a large inheritance
 tree of classes and I want to change the base class ctor (say I want to
 add another int as a parameter), I'll have to change all the ctors in
 the subclasses as well.

 Isn't that counterproductive?
Sounds like it but is necessary: Which of the constructors of the derived constructors should the compiler call after calling super's matching one? If it didn't, the derived parts would be left unconstructed. Ali
I was against this feature but Ruby implements it and I love it. I see no technical reason not to do it. The rule should be: if the class doesn't provide any constructor, just copy the constructors from the base class.
Aug 24 2011
prev sibling parent Jacob Carlborg <doob me.com> writes:
On 2011-08-24 16:59, Andrej Mitrovic wrote:
 class Foo
 {
      this(int x, int y) { }
 }

 class Bar : Foo
 {
 }

 Bar has to define its own ctor even if it only forwards the call to
 the super() ctor, e.g.:

 class Bar : Foo
 {
      this(int x, int y) { super(x, y); }
 }

 But I'm curious why this works this way. If I have a large inheritance
 tree of classes and I want to change the base class ctor (say I want
 to add another int as a parameter), I'll have to change all the ctors
 in the subclasses as well.

 Isn't that counterproductive?
You can use a template mixin as a workaround. -- /Jacob Carlborg
Aug 24 2011