Public – protected – private

Мой друг Паша на днях изложил свои мысли по поводу возможности разделения функций привычных всем модификаторов доступа еще и "модификаторами наследования"... Собственно размышления носят сугубо теоретический характер и я точно не могу судить, на сколько подобная возможность была бы востребована на практике, но сама идея кажется интересной. Собственно вот оригинал статьи:

Public – protected – private.

В последнее время стал замечать, что что-то не так в этой троице. Вроде как все просто – public это модификатор доступа, указывающий, что к элементу можно получить доступ извне, private – только другим членам этого же класса, а protected – этого же класса и производных от него. Но ведь это не так!
То есть вроде и так, но не так. Ведь если вспоминать про производные классы, то можно сказать что помеченный словом public – это наследуемый член, private – не наследуемый, а protected – снова же наследуемый.
То есть получается, что эти три модификатора – это не только модификаторы “доступа”, а еще и модификаторы “наследования” одновременно. Где

	Доступ	Наследование
Public	Public	Inherited
Private	Private	Non-inherited
Protected	Private	Inherited

Разумно было бы разделить понятия модификаторов доступа и модификаторов наследования, оставив для доступа public и private, и выделив для наследования, например, inherited и non-inherited. Тогда получим еще и четвертую комбинацию – public + non-inherited.
Многие могут сказать, что такая комбинация не нужна, но как известно применение может быть найдено всему чему угодно :) Например, вспомогательный открытый метод, который не пригодиться в производных классах. Кроме того явное использование модификаторов наследования позволит не раздувать производные классы, что в какой-то мере реабилитирует “повторное использование кода” при наследовании.

Конечно, можно предположить, что возникнут проблемы с вызовами виртуальных функций, которые есть в базовом классе, но нет в производном. Почему бы не вызывать как виртуальные только те методы, которые класс реализует от наследуемого интерфейса, так сказать подписывает контракт на реализацию. Такой метод будет гарантировать, что все нужные методы (т.е. те которые указаны в интерфейсе) всегда будут и в производных классах.