Есть так называемые «костыль-ориентированные» программисты, которые, к примеру, при исправлении бага, долго думать не будут — найдут ближайшее место и исправят прямо там. Иногда, в простых случаях, им везет, но чаще это то, что называют костылём. И да, дебагер поможет им сделать это быстрее, затратив еще меньше мозговых ресурсов. Но вряд ли отсутствие отладчика завставит его задумываться над кодом вокруг.
С другой стороны — если программист ответственно подходит к вопросу, он даже при наличии отладчика будет думать о влиянии его изменений на код вокруг, на то, какие проблемы могут возникнуть в будущем при поддержке такого решения. Все эти вопросы остаются важными для него вне зависимости от того, есть дебагер или нет. Дебагер, опять же, используется как инструмент ускорения начальной локализации проблемы.
Случаев, когда при использовании дебагера один и тот же разработчик думает над последствиями своего решения меньше, а в ином случае — больше, я пока не встречал. Впрочем, это тоже только мои наблюдения :)
Двухтысячный год. Прошло 1999 полных лет, двухтысячный еще в процессе, т.е. 2000 полных еще не прошло, XX век еще не завершился. XXI век начинается с 1 января 2001.
Я полностью согласен с тем, что у наследования реализаций в общем случае есть куча проблем. В целом, следует предпочитать агрегирование наследованию, особенно при использовании чужого кода (без разницы, открыт он или нет). Наследование реализаций все же можно использовать для внутренней кухни.
Также есть абстрактные классы, которые содержат некоторую часть реализации и предлагают реализовать некоторые недостающие методы. Разработчик абстрактного класса предлагает некий «контракт»: я тебе даю вот это, верни мне вот это, я сам тебя вызову. Класс выступает неким фреймворком, мы играем по его правилам, а не заставляем его сделать что-то, для чего его не очень-то и задумывали :) В частности, поэтому в некоторых языках виртуальными являются не все методы, а только те, которые таковыми захотел сделать автор, и поэтому просто нельзя переопределять всё, что вздумается.
Я говорил лишь о контрактах и его изменениях. В вашем примере с AddRange никто не менял контракт. Здесь другая проблема, связанная не с контрактами, а с необходимостью дополнительных знаний о реализации публичного/защищенного метода. Ее существование я не опровергаю. И действительно, изменение внутренней реализации может негативно сказаться на потомках.
Изменения в приватном «контракте» никого не волнуют, кроме владельца этого приватного «контракта» и некоторого количества извращенцев, получивших к нему доступ через рефлексию. Для наследников есть protected. И он значит для наследников ровно то же, что и public для клиенсткого кода. private — это как бы вообще не контракт. protected и public — контракты, только с разной «целевой аудиторией». Обидеть можно кого угодно с равными шансами. Если к protected относиться с такой же щепетильностью, то никто пострадать не должен.
Когда же он уже будет достаточно развит и допилен?.. Просто этого не случилось до сих пор, а комитет по стандартизации морозит и откладывает приятные новые фичи до тех времен, когда они уже совсем перестают казаться новыми и воспринимаются как нечто само собой разумеющееся.
Кровавый энтерпрайз не допускает таких вольностей =)
Втаскивать новый язык в существующий проект ради плюшек точно никто не будет. Да и новый начинать скорее всего будут на чем-то стабильном и привычном.
А дома у себя я могу хоть на чем писать, хоть на шарпе, хоть на всех JVM-совместимых языках сразу, здесь вопросов нет, доступны любые плюшки.
Да ладно вам, люди просто радуются новой фиче, вот и «спасибо», «круто», «ура». Всякий разнообразный шлак сливать будут быстро, ведь для R&C дорога только в одну сторону, а реакция сообщества здесь быстрая. Вот на Хабре да — очень хорошо еще подумать нужно прежде, чем такое вводить.
По задумке это должно стимулировать всё-таки писать статьи. Или быть ну ооочень осторожным… То есть не писать комметарии вообще. Хотя, постойте-ка… кажется, это называется read-only… Oh shi~! =)
С другой стороны — если программист ответственно подходит к вопросу, он даже при наличии отладчика будет думать о влиянии его изменений на код вокруг, на то, какие проблемы могут возникнуть в будущем при поддержке такого решения. Все эти вопросы остаются важными для него вне зависимости от того, есть дебагер или нет. Дебагер, опять же, используется как инструмент ускорения начальной локализации проблемы.
Случаев, когда при использовании дебагера один и тот же разработчик думает над последствиями своего решения меньше, а в ином случае — больше, я пока не встречал. Впрочем, это тоже только мои наблюдения :)
Также есть абстрактные классы, которые содержат некоторую часть реализации и предлагают реализовать некоторые недостающие методы. Разработчик абстрактного класса предлагает некий «контракт»: я тебе даю вот это, верни мне вот это, я сам тебя вызову. Класс выступает неким фреймворком, мы играем по его правилам, а не заставляем его сделать что-то, для чего его не очень-то и задумывали :) В частности, поэтому в некоторых языках виртуальными являются не все методы, а только те, которые таковыми захотел сделать автор, и поэтому просто нельзя переопределять всё, что вздумается.
Втаскивать новый язык в существующий проект ради плюшек точно никто не будет. Да и новый начинать скорее всего будут на чем-то стабильном и привычном.
А дома у себя я могу хоть на чем писать, хоть на шарпе, хоть на всех JVM-совместимых языках сразу, здесь вопросов нет, доступны любые плюшки.