Ответ на »сообщение 3170« (Beginner)
___________________________
Извините, конечно, косное мышление. Хотя меня немножечко прощает то, что я не из России (инородец :)

Ответ на »сообщение 3165« (Сергей Осколков)
___________________________

Нет никаких аргументов, что использование break, exit и т.д. затрудняет чтение и анализ кода. Мой опыт этого не свидетельствует.

Ok. Допустим есть некоторая конструкция, о которой говорится, что "она затрудняет чтение". Каким образом можно доказать, что она действительно затрудняет чтение? Ведь читает-то человек. А люди разные. Мы имеем эталонную модель чтения? Если нет -- дело вкуса. Т.е. вопрос вкусовщины. Так что продолжу излагать свои аргументы -- не "по существу".

Люди воспринимают информацию исходя из сложившихся у них схем восприятия (стереотипов мышления). Всё, что соответствует выстроенным у них стереотипам, является нормальным. Другое -- чужеродным, неудобным. Нужно ли менять стереотипы? Каждый для себя может решать это сам. Воспрос в критериях и приоритетах. Для одних удобство (меньше думать сейчас) важнее, нежели работа над профилактикой потенциальных будущих ошибок. Ведь будущие ошибки -- это фикция. Их сейчас нет, значит, и незачем над ними задумываться. Зачем нужна профилактика, когда есть лечение?

Ok. Мы выстроили некий нетривиальный цикл с несколькими точками выхода из него (включая несколько break/EXIT и RETURN). Затем потребовалось в цикл внести изменения в связи "с вновь открывшимися обстоятельствами дела". Его надо править. Другому исполнителю. И тут встает вопрос о том, чтобы не упустить несколько потоков управления. Т.е. задача реинжиниринга цикла (приведения его к некоему "неоптимизированному" полуфабрикатному, но понятному виду) с последующим инжинирингом в новый вид цикла.

Я не призываю безусловно отказываться от явных и скрытых goto. Просто хотелось бы, чтобы мы на некоторое время отбросили стереотипы и подумали над тем, что такой подход ИМЕЕТ ПРАВО на жизнь.

Ответ на »сообщение 3167« (...)
___________________________
признаком костного и догматического мышления
Прикольно ...
Когда в голове одна косТь, тогда мышление становится косТным :)

Ответ на »сообщение 3164« (Руслан Богатырев)
___________________________
Вместо того чтобы идти по пути устранения избыточной сложности, чтобы пытаться взять сложность под контроль

Устранить сложность или взять под контроль? Одно другому не противоречит?

Спецназ всё делает ручками, даже рефакторинг. А нам, простой пехоте, что делать - убиться и не жить, отморозить ноги и лежать? Может сложность не устранять, а дать инструменты для её контроля?
"Бог создал людей. Кольт сделал их равными".

Ответ на »сообщение 3167« (...)
___________________________
произведения Свифта о том, с какой стороны быть яйцо
Неудачно выразился. Произведение, конечно, не только о яйце и  лиллипутах, а о Гулливере.

Ответ на »сообщение 3165« (Сергей Осколков)
___________________________
Совершенно с Вами согласен. Когда кто-то начинает говорить  о вреде break, continue, return и т.д., то это мне напоминает глупые споры лилипутов из произведения Свифта о том, с какой стороны быть яйцо -  с тупой или острой. Не нравится break – не употребляейте. А мне нравится.  Если кто-то хочет из-за этого назвать меня недоучкой – пусть называет, его проблемы. Для меня это будет лишь признаком костного и догматического мышления.

Ответ на »сообщение 3140« (Jack Of Shadows)
___________________________
Рефакторинг по определению должен менять код, но не поведение программы.
Так что я не понимаю что вы имеете в виду под "архитектурным рефакторингом" ?

Рефакторинг по определению должен менять архитектуру, но не поведение программы.

Ответ на »сообщение 3161« (Руслан Богатырев)
___________________________
Обсуждение опять уходит в оффтопик.
>>>первый вариант позволяет отдавать приоритет писателям (кто заточен на быстрое написание кода и на редкое его последующее чтение и анализ).
Нет никаких аргументов, что использование break, exit и т.д. затрудняет чтение и анализ кода. Мой опыт этого не свидетельствует.
>>>А второй -- читателям, которым придется напрягаться, чтобы решить задачу -- как обойтись без break.
Эта мысль непонятна. Варианты
1)"Читатели" - это программисты, которые пишут код с тем, чтобы его потом можно было легко читать. Т.к. не доказано предыдущее утверждение, то не имеет под собой оснований и это - что те, кто пишут код, легко читаемый, обязательно стремятся избежать break, exit etc.
2)"Читатели" - это те, кто будут читать код. Тогда непонятно, зачем им напрягаться, чтобы избежать break, когда он во втором варианте уже написан без него.

>>>В первом случае думать почти не надо, поэтому вероятность допустить ошибку выше.
Почти не нужно думать там, где задача или решение - простое. А значит и вероятность допустить ошибку меньше.

Если Илья и Trurl писали по существу, то вы перешли к социологичесим оценкам, которые для меня выглядят, как нередкое здесь деление на "чистых" и нечистых".

Ответ на »сообщение 3160« (Jack Of Shadows)
___________________________

Руслан, неужели вы за включение элементов ФП  в оберон ?  :)) Я например против. Зачем  засорять хороший язык ?

Вагиф, я думал, что Вы поняли, куда я клоню.

Современные языки программирования, начав свой путь с язык-ядер все больше переползли в сферу язык-оболочек. Компактность, сбалансированность (синтаксиса и семантики), концептуальная экономия вытеснились наращиванием мускулов. ИТ-индустрия убеждала в этом потребителей, а они убеждают в этом себя.

Вместо того чтобы идти по пути устранения избыточной сложности, чтобы пытаться взять сложность под контроль, речь идет о наращивании функционала языков и придании им модных причесок. Думаю, Вы читали весьма показательное интервью с Бьерном Страуструпом "Будущее за мультипарадигматическим программированием" (2001): http://www.softcraft.ru/paradigm/common/siw.shtml

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

Почему вдруг в одном языке стали совмещать несколько парадигм, хотя должно быть очевидно, что каждая из них имеет свои законы, свой контекст применения? Потому что это видится естественно. Кто-то изучил некий язык. Он стал для него основным (любимым). Он не хочет ничего другого изучать. Но если ему разжуют и положат в рот (перетащат из другой парадигмы некие средства), он с удовольствием прожует и будет считать, что так и нужно.

Почему не приходит в голову мысль, что в другой парадигме и мыслить надо ИНАЧЕ? Другие приоритеты расставлять, ибо иной понятийный аппарат, иные сущности, иные законы оперирования ими. Получается, что программист получает гуманитарную помощь, некий заменитель, эрзац. Т.е. все равно изучает другой язык (другую парадигму), но в ухудшенном виде (притянутым за уши к его любимому языку). Простой вопрос: ЗАЧЕМ? Если речь идет о технологическом совершенстве -- то мне очевидно, что это НЕРАЗУМНО. Но если исходить из психологии людей, из консерватизма взглядов, из лени, из интересов бизнеса -- то это вполне даже нормально.

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

Разработчикам языков, когда они занимаются их реализацией, хочется, чтобы язык смог самостоятелно плавать несмотря на перекосы рынка. Это еще одна причина, почему они пытаются всё впихнуть в один язык -- тогда можно по реализации не зависеть от других (технологическая независимость). Дальше ставится вопрос взаимодействия языков. И тут либо идут по пути низкоуровневому (передаче параметров), либо по пути прокрустова ложа (.NET, Common Type System).

Теперь представим себе такую схему: выделяются ортогональные языки (представляющие ключевые парадигмы), устраняется их избыточность (нужная для построения "средневекового замка"), обеспечивается их органичная интеграция (через обобщение сущностей и надъязыковые решения, лежащие слоем выше), все это кладется на самостоятельную операционную платформу (где и формируется "средневековый замок"). А другие языки взаимодействуют с этими "привилегированными" уже на общих основаниях, как с неким факультативным средством.

Некоторые наброски контуров я уже давал: "RB23. О языках реализации в проекте новой ОС" -- http://rbogatyrev.livejournal.com/2007/07/17/ и "RB26. Дуальность и другие контуры "Росы" -- http://rbogatyrev.livejournal.com/2007/08/24/

Если резюмировать сказанное: нет надобности в Оберон включать средства ФП -- надо чикать Оберона, чикать ФЯ, делать ОО-язык, новый скриптовый, делать над ними языковую надстройку, вводить систему инвариантов...

Ответ на »сообщение 3157« (Jack Of Shadows)
___________________________
Вообще в смолтоке, насколько я помню, можно расширять существуюший класс неким отдельным способом.
В сишарп тоже ввели partial classes. То есть в отдельном файле можно дописывать методы к уже существующему классу.

Называется, слышали звон, да не знаем, где он. Partial classes в C# – это обыкновенное распределение кода класса по нескольким файлам. А расширение существующего класса новыми методами без создания наследников (и вне всякой связи с его исходниками) называется "extension methods".

Теперь о главном.

В классе Дата уже написаны три метода ВисокосныйГод, Пятница13 и ВыходнойДень, возвращающие true/false
Есть список дат. Есть выбор пользователя по какому из трех критериев отфильтровать. Выбор записан в переменной ВыборПользователя.
Нужно в соответствии с выбором венуть новый отфильтрованный список дат. Как вы это напишете на delphi\java\csharp\oberon ?


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

T[] FindAll<T> (
T[] array,
Predicate<T> match
)

И нет тут ничего сложного.