I understand Gabriel's point of view and can follow his train of thought. Nevertheless, I would like to add some comments to the philosophical side of things:
Would it be legit that a base class makes assumptions about classes derived from it?
Especially when the base class is an abstract class, as the one in the sample above implicitly is, since it contains an abstract method?
I think BlitzMax's behaviour is justified and correct. Derived classes implicitly do call the constructor of the base class, however, if this base constructor is supposed to call an abstract method, which instance of it would you expect it to call?
This question becomes more critical when the inheritance grows larger and the called method is overloaded several times. And I guess this is one of the reasons why the above code is illegal in all OO-languages.
Multiple inheritance would even add to that chaos (which is the main reason why C-Sharp and Java for example do not support multiple inheritance, except for the use in interfaces/abstract classes). Calling super in multiple inheritance adds to this chaos: To which base class refers super?
In the "good old days" of functional programming we did not have that kind of problem. And amazingly enough, the software still was able to actually solve some problems.
In the past I have worked for a compiler vendor myself, and the C++-developers there only used OO for simple encapsulation, but never for (multiple) inheritance or other more complex constructs. They probably had some good reasons for this. ;-)
Would it be legit that a base class makes assumptions about classes derived from it?
Especially when the base class is an abstract class, as the one in the sample above implicitly is, since it contains an abstract method?
I think BlitzMax's behaviour is justified and correct. Derived classes implicitly do call the constructor of the base class, however, if this base constructor is supposed to call an abstract method, which instance of it would you expect it to call?
This question becomes more critical when the inheritance grows larger and the called method is overloaded several times. And I guess this is one of the reasons why the above code is illegal in all OO-languages.
Multiple inheritance would even add to that chaos (which is the main reason why C-Sharp and Java for example do not support multiple inheritance, except for the use in interfaces/abstract classes). Calling super in multiple inheritance adds to this chaos: To which base class refers super?
In the "good old days" of functional programming we did not have that kind of problem. And amazingly enough, the software still was able to actually solve some problems.
In the past I have worked for a compiler vendor myself, and the C++-developers there only used OO for simple encapsulation, but never for (multiple) inheritance or other more complex constructs. They probably had some good reasons for this. ;-)