It is a friday evening. It has been a long week. I am going there.
So - we have a library of useful well-designed stuff. How it is designed internally is up to the designer. I am happy with the result and what I know of the internals gives me confidence in the competence and design consistency of the whole. It is why I am using it.
We have a programming language that (being C++) offers everything-including-the-kitchen-sink in the way of language features. I use a carefully chosen subset to keep code readable and efficient.
And we have a design principle, favoured in some cases but by no means all, that composition offers more design flexibility than inheritance.
And we have a keyword that ‘enforces’ the design dogma at the interface. (If you are going to play with us, you will follow what we have decided is best practice with our classes).
I get Jules’ comment above is a bit tongue-in-cheek (‘silly’, ‘beginner’ etc…) however there is a sense that this is either a) fixing a problem that does not exist, or b) promoting a dogmatic approach, not enforced by the language, into users’ code. (There is also incidentally an compiler optimization argument that I have not seen convincing evidence for.)
There is IMHO a fine line between utility and sticking your foot out and taking careful aim with a shotgun.
I resent arbitrary restriction on potential design solutions. I doubly resent re-writing functional, tested code for non-functional reasons.
I will go fix the class. In this case it is moot; the composition variation adds 40 lines of code with changes over the inheritance solution. I will swallow it.