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

4. Связь блока с именем_сущности может выполняться как на этапе компиляции (локальные сущности модуля), так и на последующих этапах (любая внешняя сущность).

Поправка. Надо читать так -- 4. Связь блока с именем_сущности выполняется статически, на этапе этапе компиляции (как локальные сущности модуля, так и любые внешние сущности).

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

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

Речь о том, что модуль с модулем связываться вообще не должны, безотносительно механизмов внутри модулей.

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

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

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

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

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

Что касается надмодульных понятий: супермодуль=кластер, то этот вопрос уже подвергался освещению.
Он находится в прямой сфере интересов т.н. кластерно-модульного программирования:
»сообщение 3590«
»сообщение 3128«
»сообщение 3168«
»сообщение 3097«
»сообщение 3114«

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


Неважно. Вопрос был о другом... Речь о том, что модуль с модулем связываться вообще не должны, безотносительно механизмов внутри модулей.

Вы хотите иметь сущьность более высокого уровня чем модули?
Назавём, например, СуперМодуль.
При этом выстраивается иерархия процедуруы, переменные, объекты объденяются в модули, с соответствующим интерфесом, а сами модули в СуперМодули, которые имеют свои интерфейсы?

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

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

Вы будете смеяться, но мне довелось заниматься системой, для которой, мы сделали возможность "на горячую" перетыкать модули БД. Локальная/сетевая/никакой.

В случае "никакой" система сохраняла возможность работать с локальными файлами в XML. В принципе можно было сделать и автоматику, типа отваливается сетевая БД, клиент прозрачно переключается на локальную, даже не заметив этого :)))))))))

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


Выдернуть "системообразующий" модуль невозможно даже из "ресурсного" ПО :)
Если подходит с такой меркой к вышеприведённой задаче, то "системообразующим" будет класс, который как раз и занят "разбором полётов" кто из БД в данный момент рабочий. Всё достаточно естественно (хотя не сказал бы, что просто :)) реализуется в ООП, но с трудом представляю, как это вменяемо сделать без оного :(

>>> На этой позитивной ноте и завершим разговор.
Ну вот так "ничего нового не сказал"! Просто не верю своим глазам!
Мирное завершение дискуссии о семантическом моделировании - это самое новое и есть.

Ответ на »сообщение 4180« (MS)
___________________________
Это к вопросу о вагончиках и рельсах.
Модуль является единой сущьностью и объявленный интерфейс является его представительством (объявлением контракта) во внешний мир. Как он его будет выполнять, в общем случае, Вы незнаете.
Это все понятно...

Может при обращению к модулю вы попадёте в диспетчер, который по своим правилам создаст связь с некой сущьностью - объектом, константой, может даже и процедурой.
Неважно. Вопрос был о другом... Речь о том, что модуль с модулем связываться вообще не должны, безотносительно механизмов внутри модулей.
(Давайте не будем начинать все сначала, если ко мне есть вопросы, то напишите и отправьте по e-mail, я постараюсь ответить)

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

Ответ на »сообщение 4174« (MS)
___________________________
>> Честно ответьте (не мне, а себе) на простой вопрос: "Подпрограмма одного модуля может обраться к подпрограмме другого модуля (даже с учетом того, что области export и import правильно оформлены)? Может или нет?".
Это не очень приятно... но с этим придется научиться жить...
> Нет, не может. Порядок доступа определятся модулем.
Может быть проголосуете? А то один одно говорит, другой - другое... Кому же верить?.. :)))
(Вы видимо невнимательно прочитали вопрос)

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

Может при обращению к модулю вы попадёте в диспетчер, который по своим правилам создаст связь с некой сущьностью - объектом, константой, может даже и процедурой.

Ответ на »сообщение 4175« (Илья Ермаков)
___________________________
Подумать над этим стоит.
Ну, вот и славненько... На этой позитивной ноте и завершим разговор.

Ответ на »сообщение 4174« (MS)
___________________________
>> Честно ответьте (не мне, а себе) на простой вопрос: "Подпрограмма одного модуля может обраться к подпрограмме другого модуля (даже с учетом того, что области export и import правильно оформлены)? Может или нет?".
Это не очень приятно... но с этим придется научиться жить...
> Нет, не может. Порядок доступа определятся модулем.
Может быть проголосуете? А то один одно говорит, другой - другое... Кому же верить?.. :)))
(Вы видимо невнимательно прочитали вопрос)

Ответ на »сообщение 4170« (info21)
___________________________
Хм.. Это называется "сформулирована"?..
С тех пор я ничего нового не сказал... можете сами сравнить...