D's constructor call hierarchy (Was: Re: [Bug 91] Inherited classes require base class to have a default constructor.)

[Lutger]

Serg Kovrov wrote:
> * Bruno Medeiros:
>> d-bugmail at puremagic.com wrote:
>>> http://d.puremagic.com/bugzilla/show_bug.cgi?id=91
>>>
>>>
>>> ------- Comment #3 from smjg at iname.com  2006-04-07 11:55 -------
>>> Yes, including C++ and Java.  If anybody could circumvent the 
>>> requirement to
>>> use a constructor simply by creating a derived a class, it would 
>>> defeat the
>>> point.
>>>
>>> You can, however, put a protected constructor in the base class.  
>>> This is a
>>> constructor created specifically for derived classes to base their 
>>> constructors
>>> on.  You would be able to completely override* a constructor if the 
>>> base class
>>> has a protected constructor that does nothing.  But can you think of 
>>> an example
>>> in which this would make sense?
>>>
>>> * Actually, constructors don't override as such.  A constructor is a 
>>> member
>>> only of the class in which it is defined, not of any derived 
>>> classes.  Hence if
>>> the base class has no default constructor, then when deriving a class 
>>> from it
>>> you must explicitly define a constructor.
>>>
>>>
>>
>> Ok, so the spec says:
>>
>> "If there is no constructor for a class, but there is a constructor 
>> for the base class, a default constructor of the form:
>>     this() { }
>> is implicitly generated."
>>
>> But why is this? Why must a derived class have it's own constructor, 
>> explicit or not? I don't think this makes sense. One time, I wanted to 
>> create a new exception class, just to throw around and make use of 
>> it's class type. So it didn't have any new content. I coded:
>>
>>   class MyException : Exception { }
>>
>> ... and surprised I was when this didn't compile, as it isn't valid 
>> code. (Because an implicit constructor "this() { }" is inserted, but 
>> there isn't a super constructor with 0 parameters). Seems to me this 
>> idea of inserting an implicit default constructor doesn't make sense, 
>> yet both Java and C# have this behavior (and C++ for what was said), 
>> so can it be I'm missing something? :/
>>
> 
> I struggling with constructor issues right now. And I am about to loose 
> my sanity.
> 
> I have toying with D for a few month now and so far everything was 
> pretty much nice. Or even better than nice =)
> Until I started with class hierarchies...
> 
> I see two major and one minor problems here:
> 
> 1. Implicit generated call for super in constructor. If i have a this() 
> constructor in base class, eventually it will be called implicitly (I 
> already experienced this). And you could spend nights trying to 
> understand why your objects misbehave. My opinion: implicitly generated 
> super() calls are Evil.

This is the same behavior as in C++. I don't think it's evil, it's a 
logical part of how class hierarchies work. So it is not a bug, it's a 
feature.

> 2. Forcing to call base constructors. I just don't get it. When I define 
> a constructor in subclass, I do it to overload functionality of base 
> classes. Isn't it obvious? But when I *forced* to call super 
> constructors, there is no sense in them at all. I some case I could have 
> some init() method to overload, but in some case i do not see a sane way 
> to fix it. My opinion: It is a design flaw, to force workarounds instead 
> of solutions.

There are a lot more details involved than I can think of right now, but 
I think it comes down to the idea that every class must be constructable 
by itself. For instance if you inherit from a class with private 
members, you can't access these private members in the derived class. So 
they need to be initialized by the parent class, hence the need for 
super. You don't want to overload constructors, if you inherit some 
implementation the base class is the proper place to construct things, 
not the derived class. For some classes to work a constructor is needed, 
if derived classes are allowed to disable these constructors it will 
create more of a maintenance nightmare.

> 3. Inability for compiler to determine suitable constructor in hierarchy 
> if no defined in current class. Programmer need to explicitly define 
> dumb constructors passing parameters to super(). My opinion: this is 
> unnecessary redundancy and could lead to maintenance hell when base 
> constructors being changed or even worse - added new.
> 
> It would be excellent if constructors in D were behave like virtual 
> methods. And not forced to call super constructors, please!!!
> 

Consider an abstract base class or interface instead and use composition 
or possibly mixins for code reuse instead of inheritance. This might 
solve such problems imho.