Ответ на »сообщение 3893« (Руслан Богатырев)
___________________________
Не воспринимайте как укол. Просто хочу пояснить свою позицию для Вас и для тех, кто наблюдает за этой дискуссией.
Хорошее начинание...

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

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

Многоуважаемому ASU предложил раскрыть свое понимание "системности" через любой конкретный язык (понятный и знакомый ему).
Хм?.. А Вы не задумывались над... постановкой своей задачи?.. Попробуйте раскрыть понимание здания, через... бетономешалку. Бетономешалка – это конкретный инструмент, применяемый при строительстве здания. Язык программирования – это тоже инструмент, применяемый при строительстве системы. Есть еще эскизы, макеты, чертежи, схемы – это все инструменты и каждый из них решает какую-то свою задачу... На эскизе можно посмотреть внешний вид, но нельзя посмотреть внутреннее устройство, на чертежах отражено внутреннее устройство, но нет ни слова об отделке помещений... Через какой «язык» Вы способны увидеть здание?..

Если этого не сделано, все остальные отсылки к правильности -- это, IMHO, вкусовщина, и надо слово "правильно" заменять на более адекватное в таком контексте "нравится" данному человеку.
Мне не нравится подобная постановка вопроса. То есть, «данному человеку» - мне и «не нравится». И все дело в том, что я изначально определил те аксиомы, относительно которых произвожу оценку. И в рамках заданной аксиоматической базы вижу несоответствие Оберона. И это оцениваю, как неправильно, постоянно подчеркивая, что неправильно с позиций теории систем.

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

Она несколько иная. Надеюсь, сам ASU развеет в ходе дальнейшей дискуссии мои опасения. Пока буду следовать презумпции невиновности.
Ха-ха-ха-ха... Вы уже и в судьи себя определили... Ха-ха-ха-ха... Н-да, уж... Во истину, «не судите, да несудимы будете»... Как я понимаю, Вы вновь готовы перевести разговор во флейм... при отсутствии аргументов?..

Возможно, я недостаточно хорошо себе представляю Ваши критерии "системности".
Моей?.. Ну, ну...

За пример спасибо. Очень подробно и понятно. С Вашего позволения, я буду использовать этот пример в дальнейшей дискуссии (хотя я уже не уверен в целесообразности ее продолжения).

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

Во избежание ввязывания в обмен эмоциями свою реакцию на неотносящиеся к делу реплики моего многоуважаемого оппонента буду просто опускать.

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

Перекоммутация делается в исходном тексте, в секции импорта. Например,

IMPORT S:=Str;

Это означает, что далее в точке использования внешней сущности он может использовать S.Size, но не Str.Size (это уже запрещается) и не просто Size. Отвечая на Ваш вопрос: программист в исходном тексте не может запретить или разрешить замену импорта. Он либо декларирует подстановку (алиасинг, именная коммутация), либо нет. Подобная возможность (алиасинг) есть и в языке Haskell.

Во втором случае -- "переключением"/подстановкой (контроль компилятора) другого значения (соответствия) -- реального имени внешнего модуля -- в секции импорта.
== Можно подробнее...

Да, можно. Я это сделал абзацем выше.

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

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

Если есть необходимость смены поставщика/потребителя, оформленного в виде модуля (группы модулей -- кластера), то в Обероне существует как режим "холодной замены" реализации модуля (до загрузки/исполнения) -- в строгом соответствии с интерфейсами, так и режим "горячей замены" (на лету, в процессе исполнения) -- контроль по тем же интерфейсам с учетом версионности сущностей.
== Кто, как и от кого узнает о необходимости замены? Как происходит процедура замены?

Необходимость замены может быть вызвана требованиями данного проекта. А кто, как и от кого об этом узнает, не имеет отношения ни к языку, ни к его реализации. Это прерогатива использования инструмента в данном проекте данной группой разработчиков.

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

Ответ на »сообщение 3889« (ASU)
___________________________
Одна из причин путаницы - опять-таки в терминах. И по этому поводу у нас с Вами недопонимание уже не первый раз.
Вы понимаете термин "системное программирование" как "программирование с применением системного подхода - системного анализа и системного проектирования". Терминологически-то может оно и более верно (хотя первый и единственный раз такую трактовку я услышал от Вас), но тогда термин "системное" вообще теряет смысл, ибо АБСОЛЮТНО ЛЮБОЕ серьезное программирование сегодня в этом случае можно назвать системным (противопоставляя "системное" - "кустарное").

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

Теперь по поводу связей.
Меня немного удивляет непонимание того, что в системе могут быть два вида связей - и гибкие, и жесткие. И у каждого вида свое назначение и свое место.
Из Ваших слов о том, как строить системы, складывается представление, что система должна представлять собой нечто амебообразное и гомоморфное... Или не так?
Нужна ли такая гипергибкость? Надежная система должна иметь скелет, каркас, построенный на жестких связях - и предоставлять разъемы, точки подключения, на которые коммутируются гибкие связи. Как можно строить устойчивую систему только на гибких связях, лично я не представляю.
В архитектуре IBM PC есть гибкие связи между материнской платой, процессором, устройствами, но сам процессор и сами устройства построены на жестких связях. А как иначе?

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

По поводу динамической коммутации.
1) "Кто выполняет переключение разъемов?"
Например, третий модуль-диспетчер. Один из таких диспетчеров - инициализационный модуль среды/приложения. Подключение разъема может выполнить при своей загрузке в память сам модуль с реализацией, но эта схема хуже предыдущей, из-за децентрализации контроля за переключениями.
2) "Почему квалифицированный импорт не мешает гибким связям?" - а почему он должен им мешать?
Я буду ниже использовать термин "лицевой модуль", за неимением лучшего. Под этим я пониманию тот модуль, "фасад", через который клиенты работают с некоторым сервисом. А сам сервис реализуется другими модулями-реализациями, про которые лицевой модуль ничего не знает.
Лицевые модули не имеют жестких связей импорта с модулями-реализациями. Они предоставляют описание интерфейсов (в виде абстрактных "классов"-записей) и разъемы для подключения реализаций этих интерфейсов (внутренние переменные и процедуры для их "переключения").
Модуль-реализация имеет жесткую связь импорта с лицевым модулем, потому что он должен использовать описание типа-интерфейса, который он реализовывает. Впрочем, если нужно сделать связь не вида "один лицевой модуль - много реализаций", а связь вида "много лицевых модулей - много реализаций", то можно эту схему усложнить, введя отдельный модуль, в котором хранятся описания интерфейсов всех разъемов. Тогда исчезнут жесткие связи от модулей реализации к лицевым модулям. Сохранятся только жесткие связи всех модулей с единственным модулем описаний.

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

Для использования внешних сущностей внутри модуля требуется осуществлять импорт. Различают:
1) неквалифицирующий импорт (без указания имени модуля при обращении к внешней сущности);
Очень правильно.

Не воспринимайте как укол. Просто хочу пояснить свою позицию для Вас и для тех, кто наблюдает за этой дискуссией.

Когда кто-то говорит слово "правильно", необходимо помнить, что правильность -- это соответствие неким правилам, некоей аксиоматике. Измените правила, измените аксиоматику -- и правильность в одной аксиоматике становится неправильностью в другой. Когда ведется дискуссия, обычно участники не фиксируют свою аксиоматику, держа ее в голове. Увы, далеко не всегда можно заглянуть в голову своему оппоненту, чтобы понять, какой свод правил он имеет в виду. Поэтому есть два варианта фиксации аксиоматики: прямой (явной формулировкой правил) или косвенный (ссылкой на эталонные публично доступные работы, либо путем раскрытия правил через другие, известные своды). В своем »сообщение 3866« я пошел по первому пути и явно сформулировал каркас (подход языка Оберон на фоне остальных вариантов). Многоуважаемому ASU предложил раскрыть свое понимание "системности" через любой конкретный язык (понятный и знакомый ему). Если этого не сделано, все остальные отсылки к правильности -- это, IMHO, вкусовщина, и надо слово "правильно" заменять на более адекватное в таком контексте "нравится" данному человеку.

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

Итак, мои ответы.

2) квалифицирующий импорт (указание имени модуля перед внешней сущностью).
Очень неправильно (с позиций системности)...

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

Неквалифицирующий импорт может быть двух видов:
1) неуточняющий (перечисление в заголовке данного модуля имен внешних модулей без указания используемых сущностей);
2) уточняющий (перечисление как имен внещних модулей, так и используемых в них сущностей).
== Что-то я перестаю понимать... Вы же сказали, что: «неквалифицирующий импорт (без указания имени модуля при обращении к внешней сущности)». Теперь говорите о перечислении имен... Как-нибудь определитесь и поясните... если нетрудно, конечно...

Постараюсь как-нибудь определиться. Есть такой язык программирования под названием Модула-2 (оставим на время в стороне Delphi и Haskell). В этом языке можно писать:

IMPORT  Str;

или так

FROM Str IMPORT Size;

Первый вариант -- предпосылка для квалифицирующего импорта. Использование сущности Size (процедура-функция, возвращающая длину переданной ей строки) будет выглядеть так:

n := Str.Size(s);

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

n := Size(s);

При этом, как нетрудно было заметить, в секции импорта (FROM ... IMPORT) упоминались как импортируемый модуль, так и используемая из него (именно из него, а не из какого-то иного модуля) сущность Size. Если программисту требуется из одного и того же модуля брать сущности как с квалификацией, так и без нее, то он может использовать обе конструкции (IMPORT и FROM-IMPORT) в одной и той же секции данного модуля. Его право.

Модула-2 запрещает использование неуточняющего неквалифицирующего импорта. Т.е. нельзя написать IMPORT Str; а потом n := Size(s). Ибо программист должен явно указать компилятору (дабы тот не домысливал за него на автопилоте), какие внешние сущности трактуются как местные (здесь и наступает точка пересечения, источник коллизии имен).

Язык Delphi поддерживает квалифицирующий импорт и неуточняющий неквалифицирующий импорт. Иными словами, он допускает писать в секции импорта

uses Str;

После этого в Delphi еще не известно, какой конкретно импорт будет применять программист (он это сделает только в точке использования внешней сущности).

Если он напишет

n := Str.Size(s);

то изберет квалифицирующий импорт (для данной сущности), если же напишет

n := Size(s);

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

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

Ответ на »сообщение 3888« (AVC)
___________________________
А теперь представьте себе, что почтовая служба -- это аналог Вашего системного загрузчика.
Куда она доставит письма в первых двух случаях (1a и 1b)?
Не знаю... Это ведь Ваше решение, почему же Вы у меня спрашиваете? Я бы решил задачу иначе:
Интерфейсы
- Адрес
-- индекс,
-- республика, область, край,
-- район
-- населенный пункт
-- улица
-- дом, корпус, строение;

- Доставка
-- Адрес корреспондента
-- Получатель
-- Адрес отправителя
-- Отправитель;
...

Ответ на »сообщение 3886« (AVC)
___________________________
Главное. "Слабые" связи тоже требуют определенного механизма.
... и... неслабого механизма... :)

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

Но взамен Вы предлагаете некий неопределенный механизм, с передачей всей ответственности системному загрузчику.
Кто сказал о всей ответственности загрузчика?.. Мной утверждалось, что
а) есть логика разработки элемента;
б) есть логика создания системы;
в) логика элемента не должна включать в себя логику системы, то есть, не должна содержать даже намека на межмодульные связи.
Большего я не утверждал.

Остаются неясными:
1) механизм межмодульного контроля типов (этим отличается раздельная компиляция от независимой);
Замените его механизмом соответствия интерфейсу (безотносительно каких либо модулей реализующих этот интерфейс). Красивее, не правда ли?..

2) механизм разрешения конфликта имен.
Каких имен? Интерфейсов? Он проверяется в тот момент, когда декларируется любой новый интерфейс, а не тогда, когда выполняется реализация данного интерфейса.

PS. Мне бы не хотелось, чтобы слово «интерфейс» воспринималось узко, как COM-интерфейсы. Такой взгляд может стать причиной недоразумений. В данном контексте, я говорю о системных интерфейсах. Любая система имеет два или более уровней. Взаимодействие между уровнями происходит посредством объявленных интерфейсов, обязательных для обоих взаимодействующих уровней.

Ответ на »сообщение 3885« (AVC)
___________________________
Мы уже выяснили, что в Обероне ни список импорта, ни квалифицирующий импорт в принципе не препятствуют тому, чтобы "слабые" связи были перекоммутированы "на лету".
Перекоммутированы кем, когда и на основании чего?

А что предлагаете Вы?
Не указывать, какие модули импортируются и не квалифицировать импортируемые идентификаторы в надежде на системный загрузчик?
Он Вам "налинкует", ага... :) Вы просто получите кучу ошибок в итоге.
Вы смотрите на задачу из Оберона... IMHO. Мышка тоже совершенно серьезно считала, что страшнее кошки зверя нет... Если речь идет о системах, то и смотреть надо с позиций системы, где язык разработки – один из множества инструментов...

В свое время мы разбирали, что одна из функций модуля -- определить пространство имен.
Да, это модульный подход. А не пробовали определить пространство имен, например, для компонента? Компонент – это тоже сборочная единица, и сточки зрения системы, что компонент, что модуль - «все едино»...

Другой момент. Вы предлагаете предоставить "слабые" связи системному загрузчику (при динамическом связывании).
Вопрос на засыпку: а как компилятор будет осуществлять межмодульный контроль типов до того как в дело вступит системный загрузчик?
А... вот... никак... и не будет. Не его это ума дело... Были в свое время линкеры... библиотекари... а сейчас "на все про все" осталось... F9. :)

Ответ на »сообщение 3883« (Руслан Богатырев)
___________________________
Чтобы не было ненужной спекуляции (и выяснения причин недовольства), к которой, как я понимаю, дело потихоньку движется, а также во избежание недопонимания я предлагаю очень простой вариант: многоуважаемый ASU вкратце объясняет свое понимание системности
Это я уже объяснил, и вроде бы меня поняли... почти все.

квалифицирующего импорта, сильных и слабых связей применительно к языку Delphi (надеюсь, это не вызовет больших затруднений). Если есть проблемы с Delphi -- любой иной язык по выбору ASU.
Хм?.. Странно все это... В отличие от Вас, я считаю что язык разработки, будь то Оберон или Объектный Паскаль, и конструирование системы... разные понятия. Проблемы тогда и возникают, когда пытаются смешивать разные понятия. Разве это не очевидно?.. Если хотите, то можно посмотреть на этот вопрос или с точки зрения языка или с точки зрения сборки системы.
С точки зрения языка разработки: пусть каждая формочка создаваемая в Delphi имеет интерфейсы, как некую декларацию своих возможностей и потребностей (здесь не подразумеваются именно COM-интерфейсы). Создадим несколько таких форм.
С точки зрения системы: наша задача собрать из этой комбинации форм несколько приложений. В соответствии с логикой каждого конкретного приложения соединяем входы и выходы форм (возможно, через преобразователи данных). Нужен ли Паскаль для такого соединения? Нет.
Теперь усложним задачу. Пусть наша система генерирует «приложения» «на лету». Для этого необходимо собрать загрузчик форм и... транслятор логики приложений. Что общего у этих элементов со средой Delphi? Ничего. Что такое логика приложений? Это некая реакция на внешние или внутренние возмущения. Или, говоря другими словами, - это некая функция от... интерфейсов вложенных форм.
Еще усложним задачу. Теперь логика приложений может тоже формироваться в процессе работы по определенным правилам(!). Очевидно эти правила будут включать в себя состояния системы, которое является суперпозицией состояний ее элементов (в частности, форм). И тогда реакция системы будет уже не простая функция, а некое предварительное логическое заключение... выбор пути решения в данных условиях...
Как видите в таком простом примере уложился целый спектр инструментальных средств: Паскаль – скриптовые языки – функциональные и логические языки. И каждому языку отведено совершенно конкретное место, где данное средство значительно эффективнее любых других.
Но, на всякий случай замечу, что создание систем – это не только языки для каждого уровня разработки, это и наборы системных парадигм, и специфические инструменты, а главное... понимание сути создаваемых систем.
А одна из заповедей системного проектирования – инкапсулируйте! Оставляйте снаружи только интерфейсы. Да, собственно, это давно уже не новость...

Вы удовлетворены ответом?

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

Ответ на »сообщение 3866« (Руслан Богатырев)
___________________________
Для использования внешних сущностей внутри модуля требуется осуществлять импорт. Различают:
1) неквалифицирующий импорт (без указания имени модуля при обращении к внешней сущности);
Очень правильно.

2) квалифицирующий импорт (указание имени модуля перед внешней сущностью).
Очень неправильно (с позиций системности)...

Прошу прощения, но выглядит это примерно так.

Почтовый адрес можно писать следующим образом:
1a) Мой адрес не дом и не улица. Мой адрес -- Советский Союз.
1b) На деревню дедушке.
Очень правильно.

2) Индекс, город, улица, и т.д.
Очень неправильно (с позиций системности)...

А теперь представьте себе, что почтовая служба -- это аналог Вашего системного загрузчика.
Куда она доставит письма в первых двух случаях (1a и 1b)?

Ответ на »сообщение 3866« (Руслан Богатырев)
___________________________
Для использования внешних сущностей внутри модуля требуется осуществлять импорт. Различают:
1) неквалифицирующий импорт (без указания имени модуля при обращении к внешней сущности);
Очень правильно.

2) квалифицирующий импорт (указание имени модуля перед внешней сущностью).
Очень неправильно (с позиций системности)...

Неквалифицирующий импорт может быть двух видов:
1) неуточняющий (перечисление в заголовке данного модуля имен внешних модулей без указания используемых сущностей);
2) уточняющий (перечисление как имен внещних модулей, так и используемых в них сущностей).
Что-то я перестаю понимать... Вы же сказали, что: «неквалифицирующий импорт (без указания имени модуля при обращении к внешней сущности)». Теперь говорите о перечислении имен... Как-нибудь определитесь и поясните... если нетрудно, конечно...

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

Существуют три варианта схем импорта сущностей:
1) cтрогая (только квалифицирующий импорт, Оберон);
Про системность здесь надо забыть...

2) смешанная (как квалифицирующий, так и неквалифицирующий импорт, Модула-2, Хаскель);
Хм... Вы решили углубиться в исследование всех реализаций импорта?.. Может быть остановимся на Оберон?

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

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

Во втором случае -- "переключением"/подстановкой (контроль компилятора) другого значения (соответствия) -- реального имени внешнего модуля -- в секции импорта.
Можно подробнее...

Межмодульные связи в Обероне формируется на основе интерфейсов (DEFINITION) и представленных в них отношений экспорта-импорта.

Чтобы использовать любую внешнюю сущность, программисту требуется:
1) указать источник заимствования (имя импортируемого модуля);
2) указать имя заимствованной сущности в месте ее использования.
Увы... Именно так я и понял...

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

Если есть необходимость смены поставщика/потребителя, оформленного в виде модуля (группы модулей -- кластера), то в Обероне существует как режим "холодной замены" реализации модуля (до загрузки/исполнения) -- в строгом соответствии с интерфейсами, так и режим "горячей замены" (на лету, в процессе исполнения) -- контроль по тем же интерфейсам с учетом версионности сущностей.
Кто, как и от кого узнает о необходимости замены? Как происходит процедура замены?

Последний вариант (горячая замена) не регламентируется описанием языка, а представлен в эталонных реализациях (Oberon System, BlackBox).
Видимо что-то из «очевидного-невероятного»...

Сильные связи в Обероне формируются декомпозицией на модули (выявление/формирование сущностей и разбиение сущностей по модулям-контейнерам).
Что такое «разбиение сущностей по модулям-контейнерам». Вы можете разбить одну сущность на несколько модулей? Зачем?..

Слабые связи -- это т.н. коммутация. Она осуществляется через:
1) экспорт-импорт (статическая/динамическая коммутация: интерфейс, раздельная компиляция, линкующая загрузка);
Кто, как и когда управляет загрузкой? Программист, который пишет модуль на Оберон? А если его модуль (А) потом использует другой модуль (Б) с другой логикой загрузки? Попробуйте представить, что первый модуль (А) и использующий его модуль (Б)... оба, но каждый по-своему, используют модуль (С). Какое решение примет загрузчик:
i) модуль (С) будет загружен только модулем (А) (или только модулем (Б)), но использоваться будет совместно;
ii) модуль (С) будет загружен дважды и его использование будет раздельным.

2) именную коммутацию импорта (статическая);
Мне в данном случае безразлично, о статике или динамике мы говорим.

3) процедурные переменные (статическая/динамическая коммутация процедур/функций/методов).
Значит модуль (А) может знать о процедурах, функциях и методах модуля (С)? Хм?..