OberonCore

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

Кажется, дошло.

Есть виртуальная общность сторов, используемая в Ex|Internalize, и там эта общность задается явно пользователем вызовами, форвардующими запрос другим сторам ... как их там, эти вызовы, кажись, Stores.Externalize( wr, s ).

А объект Domain -- это всего лишь средство в помощь механизму рассылки сообщений для рассылки сообщений только "своим" в задачах обновления изображений на экране.

Поэтому обход Store'ов нужно реализовывать через сообщения.
Придется добавлять пустой метод -- по аналогии с методом Externalize.
А вместо Stores.Externalize будет Stores.ForwardMessage.
Сообщение может быть и приказом "собраться в список", причем можно использовать какой-то предопределенный тип элементов. А имея список, можно их и обойти по одному.

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

То есть нужно добавлять пустой метод и процедуру.

Из-за добавления пустого метода придется всех клиентов перекомпилить, no?

Да, придётся.

Может, как-то выкрутиться можно? с какой-нить композицией? кто у нас особо одаренный?

Вам же в любом случае во все стандартные сторы надо будет форвардинг добавлять, no? Иначе до ваших объектов просто не дойдёт посланное, если контейнер не перешлёт.
Как вариант, можно попробовать добавить побочную работу стандартному механизму экстернализации: экстернализировать вникуда, а по ходу дела собирать ссылки на участников процесса. Далее разослать всем, кто IS MySpecialStore.

Не очевидно.

Сделаем-ка Стор2 LIMITED, а также новый СторX ABSTRACT, и будем свои умные сторы производить от СторХ, который будет всегда обернут в Стор2.
А контейнер будет иметь дело со Стор2, который то, что надо для визуальщины форвардует, а всё новое общение будут СторХ между собой делать.

No?

(Про "вариант" не понял, потом.)

Вы правы, я малость упустил из виду предмет обсуждения.Добавляем три строчки в модуль Stores:
1. в глобальный раздел TYPE: ReportStoreProc* = PROCEDURE (s: Store);
2. в глобальный раздел VAR: reportStore*: ReportStoreProc;
3. в конец метода Stores.Writer.WriteStore: IF reportStore # NIL THEN reportStore(x) END;

Создаём собственный тип Files.File, который в NewWriter создаёт экземпляр собственного Files.Writer, который ничего не делает вообще (все методы пустые). Это нужно для того, чтобы экстернализация на самом деле ни в какие файлы ничего не писала.

Далее устанавливаем обработчик в Stores.reportStore, заводим wr: Stores.Writer и вызываем wr.ConnectTo(ourFile); wr.WriteStore(documentRootView). В результате последнего вызова в обработчик Stores.reportStore должны попасть по очереди все сторы документа, причём по одному разу. Внутри обработчика делаем WITH s: MyStore DO s.HandleMyMessage(globalMessageVar) ELSE END. Механизм передачи сообщения можно усовершенствовать, это пока не важно.

Перекомпиляция клиентов Stores не потребуется, так как мы лишь добавили одну переменную и чуть подправили реализацию WriteStore.

No? : ))

Да, похоже!
Надо подумать, спасибо!

Это, конечно, трюк, но проблема, мне кажется, достаточно важна, чтобы можно было и на такой трюк решиться, пока.

Возможно, возможно...
Решение остроумное, в плане обратной совместимости.

Ну вы даёте! Это же очевидно с самого начала было.

А ещё лучше Stores выкинуть и сделать через traverse с "визитёркой".

Мне из общих соображений интересно.

Передача сторами из одной компании друг другу объектов чтения/записи -- это ведь полностью параллельно передаче сообщения.

Понятно (?), что ввод-вывод можно сделать частным случаем сообщения (передавать rd|wr в сообщении).

Или сделать rd|wr расширением сообщения?

Кстати говоря, было бы проще в сценарии А.С.И. переопределять не File, а rd|rw (?).

И тогда мы видим пример, как предоставление не-ABSTRACT типа препятствует расширяемости системы.

Спасибо за идею проталкивать сообщение как расширение от rd-wr!

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

Только там rd-wr не расширяемые.

Впрочем, по схеме АИ можно расширить файл и добиться рассылки сообщения.

-------
Мне хотелось еще понять абстракции. Нет ли изящного тут обобщения.
Вероятно, нет, но вдруг.

Как раз потому, что сообщения ходят только по фреймам виджетов, полагаю?

Ну да...

Ух, да, не расширяемые. Дёмажж.

Кстати, в Dialog.Update можно увидеть интересную схему рассылки уведомлений. По-моему, очень похоже на ситуацию с доменами:

Omnicast перебирает все окна, начиная с dir.First() и у каждого секвенсера окна вызывает хэндлер. В этом хэндлере, секвенсер окна (внимание!) опять перебирает все окна, начиная с dir.First и вызывает хэндлер броадкаста у окна - только в том случае, если окно имеет такой же секвенсер.

То есть, проявляется сборка мусора как архитектурный фактор, что ли...

Доммаж?

Файл расширяем, это решает задачу.

Но хочется найти хорошие абстракции, независимо от текущей реализации.

В качестве заметки:
- механизм выбора варианта DevSelectors требует обхода всех селекторов в тексте
- Оминк решает эту проблему частным порядком