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.
