In the previous post in this series we discussed the disadvantages of the inheritance model we initially planned for Kotlin. Today we will talk about alternative designs.
Note that these posts are intended to provoke a discussion, so that we can benefit from your feedback and come up with a better design.
What’s out there
The previous post concluded with the following (incomplete) list of solutions to the problem of multiple inheritance available in other languages:
- Java and C# have classes and interfaces, i.e. multiple interface inheritance and single implementation inheritance;
- Scala has classes and traits that may implement methods and even have state, but their constructors can not have parameters;
- Some other languages, like Fortress, do not allow state in traits;
- <Your favorite language here>
We all know that Java’s approach is rock-solid, but imposes severe limitations on code reuse, so we would like to relax these limitations, but without getting ourselves into trouble. “First degree” of relaxing the limitations would be stateless traits (like in Fortress, and in [1]): no state in traits, no implicit overrides. Or we can trade inheritance of traits off for state and get mixins (like in Ruby). Relaxing the limitations even more we get to Scala’s traits that have state but no parameters for constructors, and one trait may override functions of another. Then we get to CZ’s classes with requires (as presented in [2]). The next step, I guess, would already be unrestricted multiple inheritance, like in C++.
We will skip a thorough analysis of each of these solutions, and just make a remark about state.
Continue reading