• Andrej Mitrovic <andrej.mitrovich gmail.com> Aug 24 2011
• Ali =?iso-8859-1?q?=C7ehreli?= <acehreli yahoo.com> Aug 24 2011
• Ary Manzana <ary esperanto.org.ar> Aug 24 2011
• Jacob Carlborg <doob me.com> Aug 24 2011

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?

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

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.

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