OberonCore

Мне показалось, что у GUEST'а содержательные намерения.

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

Если регистрируется несколько потомков Files.Directory, то порядок регистрации может быть важен.

Штуки типа Files.Directory используются, скорее, наверное, все-таки для "раскрутки" системы, создаваемой с нуля.

Если в приложении в других отношениях независимые модули соревнуются, кто первый подставит свою реализацию Files.Directory, то виноват архитектор однозначно.

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

Известный мне пример, где потенциально может случиться обход запрета циклического импорта при инициализации модулей:
Dialog.Call, где в параметрах имя команды в виде цепочки литер.
Если модуль А в секции инициализации вызывает Dialog.Call с именем процедуры из модуля B, который в своей инициализации вызывает процедуру из А.
Если тут всюду имеют место прямые вызовы процедур, то B вызовет процедуру из А, когда А еще не доинициализировался.
Но если Dialog.Call правильно ставит вызов в очередь через Service.Action, то всё должно быть в порядке.

По исходнику не видно, кто инициализирует соотв. hook в Dialog, чтобы понять, что там происходит. Может, орловцы разбирались.

Реализует Dialog.CallHook модуль StdInterpreter. Там всё весьма просто сделано, очередей отложенных нет. Просто берётся через метапрограммирование адрес процедуры и вызывается.

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

А как иначе? Но Вы не ответили. Прихожу к заключению, что ответа пока нет. Тогда вопрос снимается.
Что мешает?

Фиксация порядка делается не в обычном модуле, а в специально для этого сделанном, с соотв. названием (типа Init, Config или что-то ещё), который не несёт другой смысловой нагрузки. Можно динамически грузить из его BEGIN-а.

Вот. Приятно, что не ошибся.


Неправда. Я ответил, что не понимаю Вашего вопроса.


Если нет вопроса, то и нет ответа. Ясное дело.


Пусть даже есть вопрос. Почему, если нет ответа, вопрос должен сниматься? Почему не оставить его стоять

Завтра придет разработчик и от балды впишет строчку в случайное место старой программы. Хрупкость. Да.

Насколько я понял, есть 3 пути преодоления частичной упорядоченности набора модулей, чтобы гарантировать порядок инициализации.
1. Включить (явно неиспользуемый) модуль в список импорта другого (info21).
2. Управлять порядком загрузки из специального модуля конфигурации (Илья Ермаков).
3. Явно указать линкеру порядок загрузки модулей.
IMHO, третий вариант - лучший, если список модулей ограничен и заранее известен (т.е. при линковке отдельной программы или динамической библиотеки).
Но главное - изменение состояния другого модуля из своего блока инициализации должно рассматриваться как исключение из правила (IMHO, это нужно редко).

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

Повторите вопрос, пожалуйста.
А то я добрался только до такой формулировки:Возможно, сам вопрос был задан раньше и "выпал" при "нарезке" веток.

В варианте 1. необходимые связи выражены статически, проверку делает компилятор. С этой точки зрения (максимум информации должен быть выражен статически) -- именно он лучший.
(Раз кому-то непонятно: такое включение в список импорта должно идти красной строкой с комментарием.)

С этой же точки зрения вариант 3 -- наихудший, а вариант 2 -- промежуточный.

Отсюда вывод:
В силу простоты вариант 1 -- вариант по умолчанию.
Для обоснования большей сложности варианта 2 нужен аргУмент.
Для варианта 3 -- вдвойне.

Пусть авторы 2 и 3 приведут для коллекции примеры соотв. обоснований.

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

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

IMHO, варианты 2 и 3 могут рассматриваться как применение паттерна Посредник (Mediator) из книги банды четырёх.

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

Вот это похоже на аргумент. Только насколько он не умозрительный.

А кто отрицал.


Что значит "цепляется"?

Ну, положим, у нас есть фрагмент списка импорта, который отвечает за порядок загрузки неких модулей.
IMPORT ...., A, B, C, D, ..

Почему не вынести этот порядок в IMPORT отдельного модуля, а в этом вместо списка их написать один, тот специальный? Даже если нам нужны сами эти модули тоже, лучше, по-моему, порядок зафиксировать в отдельном, импортировать его, а уже затем дописать их ещё раз.

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

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