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

Уведомление — это механизм, позволяющий установить взаимодействие между N отправителями и M получателями через посредник — верстак. Верстак может быть посредником для нескольких уведомлений, различающихся именем. Для каждого уведомления фиксируется сигнатура, одинаковая для всех отправителей и получателей. Получатель должен «подключиться» к уведомлению, чтобы его получать.  Для отправителя подключение не обязательно, но может быть сделано для оптимизации.

Зафиксируем, что уведомление определяется тройкой: (верстак, имя уведомления, сигнатура).

Перейду теперь к пунктам:

1. Что надо задать в коде Арки-клиента
2. Что надо задать в коде Арки-сервиса
3. Что надо задать в схеме
4. Что надо добавить в язык Арвиль
5. Пример кода

Поменяю порядок пунктов:

3. Что надо задать в схеме

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

• В контексте отправителя: путь верстака, имя уведомления.
• В контексте получателя: путь верстака, имя уведомления и имя принимающей команды.

Сигнатура при этом задается не в схеме, а в коде арок (она задана статически, фиксируется во время компиляции).

2. Что надо задать в коде Арки-сервиса (отправителя)

2.1. Динамический путь (JIT).

1. Арка находит верстак (по пути)
2. Арка получает функ. значение из верстака
3. Арка вызывает это ф-значение для отправки

Примерный код (предполагая, что верстак уже найден)

1. тип У = протокол {фн уведомить(парам: Строка)}
2. пусть у = верстак.отправитель уведомления(тег(У), «уведомить»)(:У)
3. у.уведомить(«Парам»)

Пояснения по строкам:

1. Используем протокол для задания сигнатуры уведомления, протокол содержит один метод.
2. Получаем объект, удовлетворяющий протоколу. Для этого, передаем тег (указатель на мета информацию о типе) и имя уведомления. Для того, чтобы определить какую сигнатуру уведомления использовать, есть несколько способов:
   • В протоколе есть единственный метод — и тогда его сигнатура и есть сигнатура уведомлений
   • Или имя метода в протоколе должно совпадать с именем уведомления (как в примере выше), что также позволяет определить сигнатуру.
   • Далее: функция «отправитель уведомления» делает динамические проверки и создает объект протокола
   • Так как в результат функции «отправитель уведомления» полиморфный (например, протокол{}), то его надо преобразовать к нужному типу протокола
   • При необходимости, до преобразования типа (:Т) можно сделать проверку типа: х типа Т.
3. Вызов — отправка уведомления. Ф-значение можно сохранить, а можно не сохранять:

верстак.отправитель уведомления(тег(У), «уведомить»)(:У).уведомить(«Парам»)

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

2.2. Путь через схему.

Настройки заданы в схеме, надо указать сигнатуру. Вариантов несколько:

Вариант 1. Синтаксическая конструкция для описания уведомления. Что-то типа:

уведомление «Имя уведомления»(сигнатура) // описание

«Имя уведомления»(аргументы) // использование в операторной части

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

уведомление (а: арка) «Имя уведомления»(сигнатура)

но это выглядит искусственно, так как имя а не используется.

Вариант 2. Синтаксическая конструкция для подключения

1. тип У = протокол {фн уведомить(…)}
2. пусть {
3. уведомить = уведомление «Имя уведомления»: У // подключение
4. }

Синтаксис условный. Здесь явно задан протокол, явно указывается переменная арки (указатель на уведомление). Настройки, так же как в варианте 1, извлекаются из схемы по имени уведомления. Вызов идет через указатель арки: а.уведомить(…). Недостаток — нет возможности изменить реакцию на ошибку (здесь будет авария, если не удалось). Впрочем, можно подумать о том, что вместо аварии, возвращается заглушка.

Реакцию на ошибку можно изменить, если написать пусть {уведомить: мб У = позже}, и делать подключение во «входе» арки.

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

1. Что надо задать в коде Арки-клиента (получателя)

Если настройки заданы в схеме, то ничего не надо кроме самой функции обработки уведомления.

В случае динамического подключения, достаточно вызвать:

верстак.подключить арку к уведомлению(«Имя уведомления», а, «Имя функции»)

Где а — это арка. Верстак найдет функцию по имени в типовой информации арки, и использует её сигнатуру для проверки. И это гораздо проще, чем я думал в предыдущих записях.

4. Что надо добавить в язык Арвиль

• Обязательно: синтаксис подключения уведомления, как часть общей инициализации
• Желательно: условное связывание, см. здесь.

Остальное после того, как будет практика использования.

5. Пример кода

Сначала надо с синтаксисом и инициализацией разобраться.