private (aka no-inherit) implementations for public methods

[Kevin Bealer]

I think I have a solution to some problems that occur in OO design.  The problems occurs when a method can be implemented that provides a great functionality for a specific class, but which it is not valid for its subclasses without extra work.  The classic examples in C++ would be serialize.

void serialize(ostream&);

A class can always implement serialize(), but it's children will have to override the method with their own definition, which will probably call parent::serialize(), then go on to copy any added fields.  If they forget, the class does not return the right data (it loses the extra fields).

The solution: even though the method is public, make it possible to mark the implementation as non-inherited.  In other words, B will inherit the signature for clone() from A, but if the user attempts to link against B::clone() they had better implement it -- such a call will not resolve to A::clone().

If B wants to just use A's version they can just call A.serialize() in their method body.  It's not a private method, it just requires developer attention one way or the other to derive from the class.

I think this would make inheritance in OO design a lot less brittle.  Note that constructors (in C++ anyway) already have this property -- they aren't inherited by default (except the default constructor).

This is because methods like serialize, toString(), constructors, opCmp, etc are 'holistic' in the sense that they address all elements of a class and it is probably an error if they miss one.  Other methods like increaseRefCount() or getName() are field-wise operations that deal with a few select member variables.

Kevin