You only ever need interface inheritance for code reuse. The genuine value proposition for implementation inheritance is, quite unsurprisingly, the same as for typestate and generic typestate, namely better type checking within a single self-contained program module.

Implementation inheritance "in the large" remains a total misfeature and should not be used, other than for very tightly defined, extensible "plug in" architectures (where the point of extensibility can itself be treated as a single module). But these are really quite rare in practice.

▲

motorest a day ago | parent [-]

> You only ever need interface inheritance for code reuse.

Not really. Interfaces play no role in invoking member functions, even if they are defined in a base class. Inheritance is used to allow member functions declared in a parent class to be called in a member functions without requiring boilerplate code. Instead of having to duplicate code, inheritance provides a concise way to specify a) this is what I want to reuse, b) this little thing is what I want to change in the implementation.

> The genuine value proposition for implementation inheritance is, quite unsurprisingly, the same as for typestate and generic typestate, namely better type checking within a single self-contained program module.

No. The value proposition is not requiring any boilerplate code to extend or change any detail in a base class. With inheritance, you just declare the thing you want to add or change, and you do not need to touch anything else. The alternatives being floated fail to meet very basic requirements such as visibility, encapsulation, and access control.

> Implementation inheritance "in the large" remains a total misfeature and should not be used (...)

Not true. This is a personal belief based on specious reasoning. You need to go way out of your way to ignore the problems that inheritance solved while ignoring the negative impact of the alternatives being floated.

▲

zozbot234 a day ago | parent [-]

> Inheritance is used to allow member functions declared in a parent class to be called in a member functions without requiring boilerplate code.

The defining characteristic of implementation inheritance is open recursion. When you call a "member function declared in a parent class" there's no telling what code will actually be run, because that member function may have been overridden at any point in the class hierarchy. There's no way of knowing whether the caller and callee code will agree on the required semantics and invariants involved, or even what these should be for any given case. That's why this is a misfeature for a "programming in the large" scenario.

By contrast, these issues can be managed when using implementation inheritance within a self-contained, smaller-scale program module, and then its open recursion behavior, properly managed, matches what we expect from the use of the typestate pattern.

	▲	motorest 5 hours ago \| parent [-]
		> The defining characteristic of implementation inheritance is open recursion. Recursion does not register as a concern in inheritance or polymorphism. > When you call a "member function declared in a parent class" there's no telling what code will actually be run, because that member function may have been overridden at any point in the class hierarchy. This is a feature, and a valuable one. You don't care what your parent class is doing. Your concern is that you want to extend it, and that's it. > By contrast, these issues can be managed when (...) You didn't pointed any issues. Also, composition addresses any concern you might have. You're searching for problems that fit a solution, and so far you pointed no problem.