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

Любая система имеет иерархическое строение, поскольку состоит из элементов (которые сами могут быть системами).

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

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

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

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

Приведу пример. У нас имеется некий файл a.txt, подлежащий сжатию (упаковке), и есть модуль File, в котором объявлена соответствующая процедура Pack. Модуль File экспортирует (через свой интерфейс) такие сущности, как тип T (абстрактный тип данных, обозначающий понятие "файл"), процедуры Open, Close, Pack.

Нормальный (предусматриваемый разработчиком интерфейса, равно как и разработчиком модуля) порядок выглядит так:

VAR f: File.T;
...
BEGIN
  File.Open(f, "a.txt");
  File.Pack(f);
  File.Close(f)
END  MyProc;

Казалось бы, все понятно. Но простите, а кто определил, что Open надо вызывать до Pack и до Close? Мы до этого додумываемся по названию? А если автор интерфейса даст другие названия? Если логика взаимодействия будет сложнее? По документации? А кто контролирует ее соблюдение? Т.е. протокол витает где-то в воздухе и мы должны до него додумываться (когда нет адекватной документации и доступа к исходным текстам)?

В отношении программной системы можно выделять слои/уровни, элементы/компоненты. Но можно и не выделять. Все зависит от подхода. Убежденность в том, что система -- это обязательно иерархическая структура, состоящая из элементов -- заблуждение. Это самый привычный и известный подход к трактовке понятия системы. Но не единственный. И не единственно полезный.

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

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

Был выдвинут тезис: квалифицирующий импорт языка Оберон противоречит системности. После всех многичисленных преамбул и недомолвок осталось дождаться четкой аргументации этого тезиса.

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

А для организации версий есть селекторы, которыми можно управлять и в "пакетном режиме".
Хм... В смысле "селекторы"?

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

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

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

ИМХО это дерево наследования.

Любая система имеет иерархическое строение, поскольку состоит из элементов (которые сами могут быть системами). Или, говоря иначе, любой «вышестоящий» элемент системы агрегирует (инкапсулирует - содержит и сокрывает) в себе элементы нижележащего уровня. Для того, чтобы элементы двух смежных (и только смежных!) уровней могли взаимодействовать им необходимо знать о соглашениях и придерживаться определенного протокола – суть интерфейсов.
Что следует из этого краткого описания? То, что понятие интерфейса появляется в момент разделения (декомпозиции) системы по уровням. Это еще даже не проектное решение, это решение которое создается на стадии анализа и моделирования. Таким образом, интерфейс создается задолго до появления какого бы то ни было программного модуля. Это первое.

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

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

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

Ответ на »сообщение 3983« (Сергей Перовский)
___________________________
>>>Все виды модульности в Обероне слиты в один
Это верно, если говорить об Оберон-системе. Но в компиляторах Оберона, сделанных в "традиционном" стиле, модули используются тоже в традиционном стиле - как едиицы компиляции.
С другой стороны, отождествление единицы компиляции и единицы загрузки не уникально для Оберона. В той же VM/CMS на IBM/370 любая единица компиляции (даже на Фортране) была единицей загрузки.

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

Хотя, возможно, более правильно поставить вопрос "интерфейс между чем и чем?".

Как Вы думаете, решение Вирта назвать развернутую спецификацию экспортируемых сущностей DEFINITION (Модула-2, Оберон), а не INTERFACE (Modula-3) не может ли быть связано с глубоким пониманием разницы между спецификацией свойств и объектов абстрагируемой сущности (модуля) и интерфейсом (который, как верно заметили, устанавливается между двумя и более субъектами/объектами)?

Ответ на »сообщение 3965« (AVC)
___________________________
>>>Честно говоря, я не очень представляю, как можно говорить об интерфейсе без модуля.
>>>Интерфейс чего?

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

Как все же мы любим применять инсрументы не по назначению.:-)
Складки задумывались как средство литературного программирования. (http://www.ssw.uni-linz.ac.at/Research/Projects/ActiveTexts.html)
А для организации версий есть селекторы, которыми можно управлять и в "пакетном режиме".

Ответ на »сообщение 3968« (AVC)
___________________________
Не так уж плохо иногда отвлечься от деталей и посмотреть на общую, панорамную картину.
Да, конечно.

Примерно такую встряску устроил нам ASU, и полагаю, что из этого можно извлечь некоторую пользу.
Хотелось бы...

Выяснилось, что о самых простых (фундаментальных) предметах мы думаем (или, по крайней мере, говорим) по-разному.
... все же правильнее... «думаем по разному»...

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

Сергей Перовский высказал предположение, что за этой точкой зрения стоит не только абстрактная теория систем, но и некоторая программная реальность, например технология COM.
COM – это паллиатив... Давайте не заслонять концепцию ее реализацией (это к добру и взаимопониманию не приводит).

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

Попробуем рассмотреть аргумент Александра Сергеевича по существу.
Обероновскому подходу (с квалифицирующим импортом) он противопоставляет некие непривязанные к модулям интерфейсы. Сразу возникает вопрос чьи это интерфейсы? (Сам ASU спросил бы -- между чем/кем эти интерфейсы?)
Отметьте, что Ваш и «мой» вопросы принципиально отличаются!..

Второй вопрос: как должен решаться конфликт имен? Или программист должен отслеживать все имена в системе, чтобы избежать ошибок?
Нет... Все гораздо... проще... на несколько порядков...

Во всех языках, рассчитанных на создание крупных программных систем, для решения этой проблемы были введены специальные механизмы. В тех языках, где нет явных модулей, были введены пространства имен (например, в C++ и C#). Но ASU не говорит ни слова об этих мезанизмах.
В силу их бесполезности...

У меня также создалось впечатление (вероятно, ошибочное), что ASU отрицает иерархическое устройство систем (это было бы очень странно). Мол, части системы взаимодействуют, ничего не зная друг о друге, без всякого иерархического соподчинения.
Это ошибочное суждение. Любая система иерархична... по определению.

Да, такое может быть, но только если о взаимодействии этих двух несведующих частей системы позаботилась третья, более осведомленная.
Правильно... позаботиться должна система... (та самая третья «сила»).

Поэтому я считаю, что сам вопрос, поднятый ASU, возник вследствие недоразумения, но обсуждение этого вопроса вполне может оказаться полезным, устраняя подобные недоразумения.
Недоразумения?.. Хм... Если и есть какое-то недоразумение, то оно порождено не вопросом, а восприятием... IMHO... :)