Ответ на »сообщение 4002« (Сергей Тарасов)
___________________________
Отсутствие горизонтальных связей?
Да, без компромиссов... Горизонтальная связь = «слабая» связь. То есть, верхний уровень связывает два элемента так, как считает нужным.

Тогда, конечно, не надо специфицировать интерфейс.
Надо, но только между уровнями.

И полиморфизм не нужен.
Нужен, причем полноценный. Как, впрочем, и механизм поддержки синонимов.

Ответ на »сообщение 3992« (ASU)
___________________________


В остальном придерживаются строгого правила: интерфейсы локализованы между двумя уровнями. Поэтому не происходит никакой путаницы с именами и не требуется вводить дополнительные правила, поддерживающие пространства имен. Данное требование должно быть «известно» и средствам трансляции, и средствам загрузки, и средствам коммутации.
Прекрасно. Но почему ипморт и полная квалификация противоречат этим принципам?
Я уже говорил, напомню еще раз - производится всего лишь импорт спецификации интерфейса модуля. Все. Подстановку реализации производит "система" (загрузчик, а еще до этого - пользователь, конфигуратор, программа установки, которая копирует соответствующий кодовый файл, который будет реализовывать соотв. интерфейс).
При этом реально загруженный модуль может спокойно поддерживать более "широкий" интерфейс, чем тот, под который компилировались его клиенты. Более того, у нескольких клиентских модулей могут быть различные версии спецификации интерфейса модуля, если они создавались в разное время под разные версии этого интерфейса. Главное, чтобы они не противоречили друг другу.

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

Это сильно упрощает схему: все "уникальные" блоки системы строятся непосредственно на модулях, блоки, которые могут множиться и версионироваться "на лету" строятся на основе абстрактных и объектных типов данных.

Ответ на »сообщение 3992« (ASU)
___________________________


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

Ответ на »сообщение 3997« (MS)
___________________________
ООП vs Модульное программирование?
С этим не ко мне... С моей точки зрения, есть четкая последовательность:
процедуры -> библиотеки -> модули -> объекты -> агрегаты -> системы...
и никаких "противоборств"...

Ответ на »сообщение 3992« (ASU)
___________________________


Каждый элемент какого-либо из уровней может обращаться только к своему агрегату, он ничего не должен знать ни о системных службах, ни о смежных элементах. Соответственно, интерфейсы системных служб дополняют межуровневые интерфейсы, так, как будто они принадлежат агрегату. И агрегат имеет возможность перехватывать обращения своих элементов.
В остальном придерживаются строгого правила: интерфейсы локализованы между двумя уровнями. Поэтому не происходит никакой путаницы с именами и не требуется вводить дополнительные правила, поддерживающие пространства имен. Данное требование должно быть «известно» и средствам трансляции, и средствам загрузки, и средствам коммутации.
Отсутствие горизонтальных связей?
Тогда, конечно, не надо специфицировать интерфейс.
И полиморфизм не нужен.

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

Я бы и хотел по всем 12 пунктам сравнений вам ответить, но понял, что в отсутствии опыта работы с Обероном это займет непозволительно много времени.

Чтобы задача не казалась такой неподъемной, ее можно упростить. Есть специалисты по одному языку, участвующему в сравнении (Delphi), есть по другому (Oberon). Достаточно отметить некорректность (неполноту, ошибочность) утверждений, относящихся к соответствующим языкам. Либо отметить некорректность в отношении методики сопоставления (не те критерии, не те разделы).

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

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

Ответ на »сообщение 3965« (AVC)
___________________________
Таким образом мы получаем гораздо более слабые связи между текстами модулей. Поскольку интерфейсы регистрируются и вызываются при помощи GUID никакой конфликт имен невозможен.

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

Вы же не можете позволить себе использовать громоздкий COM каждый день для каждого мелкого модуля Вашего приложения? А я в Обероне могу. Каждый отдельно взятый модуль автоматически становится динамически связываемым компонентом, без приложения каких-то особенных усилий.

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

Сергей, есть небольшая разница между низким порогом входа и тщательным изложением совсем непростых вещей. Вас интересует низкий порог входа в язык Оберон? См. http://www.oberon2005.ru/obe_faq1.html и http://www.oberon2005.ru/obe_faq2.html

Вас интересует низкий порог входа в различие модулей Delphi и Оберона? Ok. Я собственно и сказал, что готов это сделать, но после того как получу предметную критику на упомянутую работу. Осталось только ее дождаться.

Ответ на »сообщение 3853« (Владимир Лось)
___________________________

Семь лет мы тут воду в ступе толчём, а где результаты?
Инфо21 что-то тут о курсах говорил - не видел я что-то на развалах хотя бы брошюрок на тему КП с надписью на титульном листе "рекомендовано... для применения в курсах обучения"... Академик, ведь - это не вася пупкин - из заштатного ПТУ... Всё прекрасно, но как-то "ограниченно-точечно-кулуарно"...
Душкин вон напечатал книгу по Хаскелю. Книжка немного сумбурная, слабая, оформлена - из рук вон... Но посмотрите на эффект, сколько дискуссий возникло. С полок её смели (говорят даже издетельство ещё раз отпечатает партию), Душкин вторую книгу готовит. У меня студенты и знакомые стали связку слов "хаскель-ФП-книга Душкина" ЗАМЕТНО чаще употреблять... ПОстепено, кстати, складывается впечатление, что все, сколь-нибудь значимые и передовые исследования в мире программирования перемещаются в нишу "хаскель" и "ФП"... Не знаю, насколько это верно объективно, но "информационный фон" именно таким стал...

А здесь - что? Тем более при вашей лично, Руслан, кипучей деятельности, много- и связнословии и возможности контакта с "прессой"?

Полностью вас поддержу.
Руслан, я глянул на вашу статью о сравнениях. Она является типичным примером того, о чем говорит Владимир.
Я бы и хотел по всем 12 пунктам сравнений вам ответить, но понял, что в отсутствии опыта работы с Обероном это займет непозволительно много времени. На беготню по ссылкам (ссылка на книги по описанию языка так же полезны, как и на большую советскую энциклопедию), на поиск определений и их сопоставлений, на поиск примеров и контрпримеров.
Поэтому не стоит удивляться, что студенты начинают употреблять связку слов "хаскель-ФП-книга Душкина". Видимо (книгу не читал), Душкин сумел передать сложные веши простыми словами и на конкретных примерах.
Низкий порог входа - великое дело. И совершенно необязательно за низким порогом стоит примитивная технология. Это может быть первый шаг к сложной системе, первый шаг без которого путь в 1000 шагов никогда не начнется.

Ответ на »сообщение 3994« (ASU)
___________________________

Ответ на »сообщение 3993« (MS)
___________________________
ИМХО это дерево наследования.
Агрегация...

ООП vs Модульное программирование?