Когда мы так делаем, то сами берем на себя ответственность, после такого компилятор "умывает руки". Изменение области видимости помогает избежать ошибок при работе с текущим классом. 

  Я не слышал такого чтобы в С++ можно было спрятать отдельный метод.

Alexeis, полностью с тобой согласен. 

_________
И вот все равно не понимаю почему нельзя понизить видимость метода в наследнике. Если кто-то скажет что это ООП, и там все логично, тогда я скажу а разве мой пример не логичен?

Можно сделать через Inherited, но объявить метод как inline, результат будет такой как нужно и синтаксически и бинарно.

Вообще-то, как правильно уже заметили, это ошибка проектирования. Поэтому такая "фишка" - это костыль, помогающий решать эти проблемы. Может это и отлично ложиться в философию C/C++ ("мы дадим в руки программистам самые мощные инструменты, но они обязуются использовать их грамотно и во благо"), то уж точно не годится в Delphi.


Нет, не логичен. Вы допустили ошибку при создании класса TSomeClass и исправлять надо её, а не городить огород вокруг.

  Всего не предусмотришь, а менять реализацию уже работающих классов не лучший вариант.

ну да


в смысле сделать inherited

Ну так как уже говорили с объявлением того же метода в наследнике, т.е. вот так

Ааа, понял. ну что ж как вариант...

Лучший вариант нагородить бредового кода в который без высоких сапог и резиновых перчаток лучше не суваться?

  Голословное и безосновательное утверждение попахивающее наездом. Я лично не видел кода 
Delphist. Вы его видели? Или судите так категорично обо всем только исходя из того что одна функция оказалась не в той области видимости?

Я не именно о варианте Делфиста, а вообще о подходе исправлять ошибки проективарония костылями. Мне кажется это не верный подход, который только запутывает код и многие вещи делает не очевидным. Если метод public  то он он паблик, и не надо мучатся почему в n-ом предке куда то пропал этот метод. Наличие таких возможностей чревато перегибами в его использование, по тому мне кажется что лучше, что бы таких возможностей вообще не существовало.
ЗЫ извини за наезд  

Это сообщение отредактировал(а) cemick - 4.4.2009, 13:40

Поддерживаю cemick и полностью с ним согласен. Сам хотел такое написать, но опередили.

  Не сомневаюсь. Хаить чужой код все мастера... Есть конкретная жизненная ситуация, для таких ситуаций должно быть эффективное решение, иначе получается что не язык для программиста, а программист для языка.

Добавлено через 3 минуты и 9 секунд
  Точно также как в свое время ввели дополнение класс хелпелпер, позволяющий безопасно расширить существующий класс не меняя код его реализации. Реальность такова что весь софт нуждается в поддержке и доработке, даже после ухода программиста, который его писал. В этом случае безопасность модификаций имеет первостепенное значение.

И чем же ушедший на пенсию программист мешает нам сменить видимость метода?

  В теме же написано что от него поражаются и другие наследники, которые используют этот метод, если его скрыть они перестанут работать.
  Вот смотри есть класс TStream, который умеет читать и писать в абстрактный поток, для него есть TFileStream, который умеет реально читать и писать, но от TStream наследуется также TResourceStream, который писать не может по определению, однако ж методы записи у него унаследованы от TStream. Использовать их будет ошибкой программирования, хотя синтаксически компилятор съест. Борланд решил вопрос сгенерировав ошибку в run-time, это правильно если мы работаем с TResourceStream как с предком т.е. TStream, однако неверно при работе с TResourceStream, поскольку метод есть, компилируется верно, но при работе вызывает ошибку. Идеальным было бы скрыть в TResourceStream методы write, writeBuffer, copyfrom, поскольку они лишь путают, но не несут ни какой пользы. Но это не делается ввиду того что необходимый механизм скрытия методов попросту отсутствует.