Ответ на »сообщение 3965« (AVC)
___________________________
Интерфейс есть не частный случай модуля, а внешнее представление модуля.
О! Начинаем... докапываться до сути... Несмотря на искреннее уважение и благодарность... согласиться с Вами не могу... ни на йоту.

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

Ответ на »сообщение 3962« (Сергей Перовский)
___________________________
интерфейс может быть ТОЛЬКО абстрактным. Синтаксический минимализм, это конечно приятно, но считать интерфейс частным случаем модуля все таки не стоит.
Поддерживаю! На все 100% :)

Ответ на »сообщение 3954« (Mirage)
___________________________
Судя по всему вы слегка не поняли что собственно представляет собой (или может представлять) модуль. Это ведь самый что ни на есть интерфейс.
Не исключено, что я «слегка не понимаю», что представляет собой модуль... Но совершенно точно, что термин «интерфейс» мы с Вами понимаем совершенно различно... :)
Чуть позже я поясню...

Кстати, если квалификация модуля противоречит теории систем, то квалификация поля классом тоже противоречит.;)
Нет, не противоречит.

Ответ на »сообщение 3980« (AVC)
___________________________
>>>Тем интереснее будет сопоставить дельфийские и обероновские модули, чтобы понять, как такое может быть: модули в языке есть, но они "на вторых ролях".
Прочитайте указанную статью Богатырева, там все достаточно точно разобрано. Дельфийские и обероновские модули абсолютно разные вещи. Просто некоторые сторонники Оберона используют прием ASU: модуль, это то, что в Обероне, а то, что раньше называли модулем, это неправильно :)
Все виды модульности в Обероне слиты в один: "Оберон-модуль является унифицированной единицей компиляции, компоновки, загрузки и замены"(с) Руслан Богатырев.
В некоторых задачах это удобно. Но, вообще говоря, разбивка на единицы компиляции, компоновки и загрузки может вестись из различных соображений и "принудительная уравниловка" меня не слишком привлекает.
В Дельфи program и library создают модули компоновки и загрузки, а unit-модули трансляции. На мой взгляд это удобнее.
Тут опять имеет место синтаксический минимализм. Ничего не имею против этого подхода, но IMHO слишком часто в случае с Обероном  синтаксический минимализм балансирует на грани разумного.
Насчет того, что модули в Дельфи на вторых ролях я не соглашусь, это очень важный и полезный инструмент.

Ответ на »сообщение 3965« (AVC)
___________________________
>>>Интерфейс есть не частный случай модуля, а внешнее представление модуля.
Я уже много раз указывал на СОМ технологию - там интерфейс это отдельная сущность, регистрируемая в ОС. Если какая нибудь задача запрашивает работу с некотором интерфейсом, система ищет, кто зарегестрирован, как исполнитель данного интерфейса. Таким образом мы получаем гораздо более слабые связи между текстами модулей. Поскольку интерфейсы регистрируются и вызываются при помощи GUID никакой конфликт имен невозможен.
К сожалению, СОМ интерфейсы могут включать только процедуры. Но к рассматриваемым механизмам это отношения не имеет.

ответ на »сообщение 3980« (AVC)

Лично для меня знакомство с "настоящими делфийскими модулями" произошло следующим образом: как-то мы решили на скорую руку собрать приложение из отдельных exe-х, "по рабоче-крестьянски", с помощью WinExec. Через некоторое время мы "вдруг" заметили, это наше "архитектурное" решение наиболее устойчиво, благополучно переходит из проекта в проект, очень удобно с точки зрения модификаций и т.д. и т.п. Правда пришлось немного поизощряться с организацией взаимодествия наших "модулей". В частности для "тонкого" взаимодействия используем обмен сообщениями (WMCopyData). В общем мы поняли, что такое настоящие модули и чем они отличаются от unit-ов.

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

>>>Могу сказать точно, что работа в Дельфи и чтение различной литературы по ней для меня ничуть не способствовало правильному пониманию сути модулей. Модули в Дельфи повсеместно "на вторых ролях": ну, есть - и ладно. Программируя несколько лет на Дельфи, я так и не прочувствовал модульности.

Это очень интересный факт, а для меня так прямо -- неожиданный!
Я почему-то предполагал, что "дельфийцы" в более выгодном (по сравнению со мной) положении для освоения Оберона.
Тем интереснее будет сопоставить дельфийские и обероновские модули, чтобы понять, как такое может быть: модули в языке есть, но они "на вторых ролях".

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

Ответ на »сообщение 3975« (Руслан Богатырев)
___________________________
Возможно, стоит провести опрос среди самих "оберонщиков": как именно они усваивали понятие модуля? Помогало ли им знание родственных конструкций других языков (например, дельфийских модулей)?
Т.е. осознать собственный путь к модульности и извлечь отсюда уроки.
Могу сказать точно, что работа в Дельфи и чтение различной литературы по ней для меня ничуть не способствовало правильному пониманию сути модулей. Модули в Дельфи повсеместно "на вторых ролях": ну, есть - и ладно. Программируя несколько лет на Дельфи, я так и не прочувствовал модульности. Поэтому после перехода на С++ даже воевал на дельфийских сайтах, доказывая, что "в С++ модули есть, и более гибкие, чем в Дельфи - хотите инклюд, хотите наймспэйс..."

Знакомство с модульностью началось позже, с языка Ada. Концепция пакетов, раздельной компиляции, сокрытия "внутренностей", разложенность по полочкам, конструктивная продуманность восхитили. Ну а потом "случился" Оберон :-)

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

Т.к. мы находимся на дельфийском сайте, отталкиваться от модулей Delphi вполне логично, т.к. многим они знакомы.

Тогда было бы неплохо, если кто-нибудь из спецов по Delphi глянул мое старое сравнение: http://www.europrog.ru/qa261005.html

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

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

>>>А такой ли модуль Оберона уникальный, что его устройство непонятно? Может, пояснять на примере чего-то известного, например, модулей Delphi?

Вопрос интересный.
Т.к. мы находимся на дельфийском сайте, отталкиваться от модулей Delphi вполне логично, т.к. многим они знакомы.
Мне же пришлось усваивать это понятие практически с нуля, т.к. я почти всю жизнь пишу на Си/Си++.
Естественно, что в Обероне меня привлекли сначала не модули, а то, что info21 удачно назвал "герметичностью" системы типов. Просто я настрадался в Си с противоположностью этой "герметичности". Так что откликнулся на type safety и сборку мусора весьма живо.
А вот модули поначалу я не особенно воспринимал (ну есть, и хорошо).
Проникся позже, и теперь обратная картина: уже думать не могу о "немодульных" решениях.

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