Ответ на »сообщение 3193« (Илья Ермаков)
___________________________

Сергей, Вы упорно и все время увиливаете от ответа на вопрос - чем Вам не нравится решение через делегирование? :-) Оно объективно лучше даже для личного использования ...

Подтверждаю.
У меня проблема с экспериментированием со сложными функциями, с которыми много чего надо делать -- "эволюция на стероидах".
Обычное наследование отдыхает. Ничто не работает так, как стандартные ББ схемы, которые описывает И.Е. и AVC -- делегирование, oberon bus и т.д.

Ответ на »сообщение 3176« (Руслан Богатырев)
___________________________

К тому же КОП на уровне языков практически не представлено, это выводится на внеязыковой уровень.

По-моему, модульное программирование также следует вынести на внеязыковый уровень.

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

В языках ML-семейства модули (особенно параметризованные) вообще являются единицами абстракции данных (классов типов ведь там нет).

По сути остаются две парадигмы: ООП (включающее в себя императивное программирование) и ФП.
Модульные языки есть и в той, и в другой группе.
Компонентные... Вапще-то я не знаток ФП, но думаю, лиспы можно отнести к компонентным языкам. Но тут уже да, вопрос больше к Jack Of Shadows и Lisp Hobbyist... Эрланг, думаю, тоже можно (вопрос, наверное, к Trurl)... В лиспах и Эрланге вполне возможно выгружать/перезагружать модули-компоненты на лету, насколько я знаю...

Ответ на »сообщение 3176« (Руслан Богатырев)
___________________________

Для ФП -- вопрос к Джеку (желательно, одну-единственную).

Я извиняюсь, а можно мне предложить? ;о)

Антони Филд и Питер Харрисон, "Функциональное программирование" (14 МБт)

Книга Хендерсона с таким же названием считается уже устаревшей, а вот книга Филда и Харрисона - вполне адекватной...

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

Ответ на »сообщение 3188« (Илья Ермаков)
___________________________
Меня волнует время разработки и эффективность работы прикладной программы. И оценки получаются совершенно другими. Вопросов, "что будет если кто-то вздумает внести изменения" тут просто на возникает.
Сергей, Вы упорно и все время увиливаете от ответа на вопрос - чем Вам не нравится решение через делегирование? :-) Оно объективно лучше даже для личного использования - меньше ломок и переделок в процессе роста системы...

Я примеры с грузовиками тут приводил для чего - чтобы продемонстрировать нелогичность наследования реализации как факта... :-)

Ответ на »сообщение 3190« (Рулсан Богатырев)
___________________________

в сфере искусственного интеллекта давненько в ходу были семантические сети (до первой Симулы), ну а с появлением фреймов и слотов Марвина Минского (где-то в районе 1975 г.) стало понятным (все ведущие ученые тогда варились в общем котле и активно общались друг с другом не только на конференциях), что классы-фреймы -- это сильное средство построения информационных моделей.

Если продолжить развивать мысль в данном направлении, то ООП зиждется на моделях того, как человек мыслит и как это понимание увязать с "машинным" мышлением. А это епархия романтиков ИИ. Можно сказать даже: soft-часть в software. Модули -- это "примитивные" инженерные конструкции, железные ящики, реалии жизни. Hard-часть в software. Ну а ФП -- это ware-часть в software, квинтэссенция математики, царицы наук. Куда уж без нее. :)

Предлагаю поднять тост за архитекторов-инженеров-математиков программирования, за плодотворный союз ГАПов (главных архитекторов проекта) от ООП, ГИПов (главных инженеров проекта) от МП и инженеров-математиков от ФП!

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

Ответ на »сообщение 3188« (Илья Ермаков)
___________________________
>>>И приехало - всем модулям по всему миру потребовалась перекомпиляция...
Вот тут и проходит водораздел.
...
Если я или кто-то другой попробует часть иерархий использовать для другой задачи, то сначала нужно будет убедится в математической адекватности соответствующий части задачи.

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

Ответ на »сообщение 3188« (Илья Ермаков)
___________________________

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

На самом деле, получается довольно интересная картина. Вирт, если не ошибаюсь, ввел в обращение ссылки (Euler). Хоар придумал class record, т.е. записи со ссылками (не забыв упомянуть Вирта). Дал и Нигаард взяли идею Хоара (также сказав об этом) и довели в Симуле-67 до process class (или просто class), соединив универсальную структуру данных (record) с функциональностью. Т.е. предложили инкапсуляцию (не надо путать с information hiding Парнаса). Американцы в Xerox PARC ввели в язык Mesa (делался на основе Паскаля, Алгола-68 и Симулы-67 с учетом BCPL) процедурные переменные, создав основу процедурного делегирования. Делегирование -- это просто коммутация с предобработкой. Вирт включил это в Modula-2, а затем оно проникло в Обероны, где базисом (помимо модулей) выступают все те же class record Хоара в виртовской интерпретации (type extension). Кстати, модули Оберона пришли из модулей Modula-2, а те, в свою очередь, из модулей Mesa. А модули Mesa делались на основе работы Парнаса (раннюю работу Наура они похоже не читали), причем за основу брали... классы Симулы-67. :)

Одной из интересных идей Mesa был binding mechanism, т.е. динамическое связывание процедур. Ныне это называют late binding (отложенное связывание). В общем-то, процедурная коммутация на этом-то и строится.

Что касается идей применения хоаровской конструкции record в качестве основы ООП (для выражения отношений между сущностями), то в сфере искусственного интеллекта давненько в ходу были семантические сети (до первой Симулы), ну а с появлением фреймов и слотов Марвина Минского (где-то в районе 1975 г.) стало понятным (все ведущие ученые тогда варились в общем котле и активно общались друг с другом не только на конференциях), что классы-фреймы -- это сильное средство построения информационных моделей.

Если почитать нынешние статьи по ООП, то частенько видишь рекомендации: побольше абстрактных классов и делегирования. Собственно, в Оберонах к этому давно уже пришли. И для этого не надо было городить огород гигантских проектов.

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

Ответ на »сообщение 3188« (Илья Ермаков)
___________________________
>>>И приехало - всем модулям по всему миру потребовалась перекомпиляция...
Вот тут и проходит водораздел. Если Вы пишете для всего мира и собираетесь впредь поддерживать и модифицировать свою продукцию, то никакие расходы на безопасность и стандартизацию не являются избыточными.
Между прочим в Дельфи все пришли к этому давно: наследовать можно только от стандартных компонент, сторонние компоненты можно использовать только as is.
Меня волнует время разработки и эффективность работы прикладной программы. И оценки получаются совершенно другими. Вопросов, "что будет если кто-то вздумает внести изменения" тут просто на возникает. Есть, заранее установленная область применимости, есть математическое решение задачи. Системный анализ однозначно выделяет инвариантные части различных сущностей (как атрибуты, так и функции), выстраивая систему иерархий. Никакой опасности бесконтрольной модификации нет.
Если я или кто-то другой попробует часть иерархий использовать для другой задачи, то сначала нужно будет убедится в математической адекватности соответствующий части задачи.

Продолжу пример - о преимуществе делегирования перед наследованием реализации.

Буду пример из привычного для меня - из стандартных типов ББ.
Текстовое отображение TextViews.View.
Сделано по всем правилам компонентности - наружу только полностью абстрактный View, реализация StdView спрятана внутри модуля. Экземпляр создается через каталог TextViews.dir. dir можно подменить снаружи, вызвав TextViews.SetDirectory, и вся среда начнет прозрачно работать с другой реализацией текста. Все как положено, в общем. Однако нас волнует проблема повторной используемости - как быть без наследования реализации? Наследоваться-то от StdView не можем, он нам недоступен. Если нам нужно изменить в поведении стандартного текста какую-то мелочь, обидно переписывать полтысячи строк кода.
Опять же - делегирование. Пишем свою обертку - потомок TextViews.View, которая небольшую, особую часть выполняет сама, а все остальные вызовы перенаправляет к "обернутому" экземпляру StdView. В чем проблема? Получили то же самое наследование реализации, только вылепленное руками. С одной стороны убедились, что можно и без него - чуть-чуть побольше кода. С другой стороны - неясно, если получили то же самое, то зачем огород городить?

В том-то и дело, что то же, да не то же...
В варианте с делегированием нет никакой статической зависимости между нашим типом-оберткой и типом, который выступает в роли заготовки реализации (TextViews.StdView). Связь-то только через абстрактный интерфейс TextViews.View! Это ведет к очень долгосрочным последствиям.
Как уже говорилось, TextViews.dir можно подменить, и стандартной для всей среды реализацией станет другая. Наш тип тут же начнет использовать новую реализацию, совершенно прозрачно для себя. Да ему вообще наплевать, от какого типа "наследовать" реализацию, потому что, пардон за тавтологию, наследует он ее не через наследование, а через делегирование!

А если бы все было "как в Дельфе". Ominc открыл бы StdView для наследования. Все унаследовались по самое некуда. Затем в новой версии среды потребовалось чуть-чуть "колыхнуть" StdView - ввести новое внутренне поле, например. Размер типа данных изменился - представление всех типов-расширений поехало. И приехало - всем модулям по всему миру потребовалась перекомпиляция... А если нет доступа к исходникам, не open-source?

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

Наследование - это способ выразить отношение "род-вид". Например, грузовик - это автомобиль. Тут есть наследование интерфейса - и прекрасно.
Теперь прочувствуем абсурдность наследования реализации. Мы хотим повторно использовать функциональность автомобиля в грузовике.
Если мы выбрали для этого способ наследования реализации - это значит, что все грузовики используют функциональность одной-единственной реализации автомобиля!
Пусть кто-то реализовал тип "дизельный автомобиль". Ах, как прекрасно! Ведь "дизельный автомобиль" - это тоже автомобиль. Почему бы грузовику не использовать повтороно функциональность из дизельного автомобиля? Ах, какая жалость... Мы не можем перенаследовать грузовик от дизельного автомобиля - поломаем всю иерархию. Ведь кто-то уже наопределил кучу потомков грузовика. А кто-то сделал свой дизельный автомобиль, который потомок грузовика.
А если появится реализация "гусеничный автомобиль" - и мы захотим повторно переиспользовать реализацию оттуда... Нам множественное наследование ну просто позарез нужно. Но и его не хватит... Потому что сама идея выражения повторного использования через наследование, вмешивания в отношение "A есть разновидность B" зависимостей "А реализовано через B" - это бред.

Небольшой офтопик, но информация важная.

Сегодня в Токио прошел финал чемпионата мира ACM по программированию. Напомню, что участвуют лучшие студенческие команды, прошедшие сито предварительного отбора. В этот раз победили поляки (Warsaw Univ.) -- 8 решенных задач из 10. Прошлогоднее серебро они поменяли на победу в абсолютном первенстве. Вторыми были китайцы (Tsinghua Univ.) -- 7 задач, третьими наши (СПбГУ ИТМО) -- 6 задач. Американцы в этом году реабилитировались за неудачи последних лет: команда MIT заняла четвертое место (одинаковые показатели с питерцами) и вошла в "золотую" зону (первой четверке вручают золотые медали).

Далее следует еще 9 команд, решивших 6 задач, но набравших больше штрафных минут (с учетом неудачных попыток сдачи). Серебро и 5-е и 6-е места соответственно у Новосибирска (НГУ) и прошлогодних чемпионов -- команды Саратова (СГУ). Бронза и 10-е место у МГУ. Не повезло команде Петрозаводска -- 13-е место с теми же 6-ю задачами, но в шаге от бронзы. Итого у России в этом году 1 золото, 2 серебра и 1 бронза. У американцев -- 1 золото и 1 бронза (California Institute of Technology). У Китая -- 1 золото и 1 серебро (Shanghai Jiao Tong Univ.). В этом году прошло без особых сенсаций -- 7 медалистов прошлого года были в медалях и на этот раз.

Финальная таблица здесь: http://icpc.baylor.edu/icpc/Finals/scoreboard/Final/
Промежуточное табло (заморожено за час до конца) здесь: http://icpc.baylor.edu/icpc/Finals/Scoreboard/default.htm

Ниже "ватерлинии" (Honorable Mention без указания мест) наши не опустились. 5 задач решил С.-Петербург (СПбГУ), по 4 -- Ставропольский и Уральский университеты, а также Вологодский педаг. университет. 3 задачи решила команда Орловского гос.тех.университета.

В общем, наши подтвердили свой высокий класс и выступили успешно. Молодцы!