OberonCore

Выработалась концепция инструментального подхода. Если совсем просто, то инструмент - это указатель на объект без полей данных. Как Log.Hook. Но для такого инструмента не требуется выделять динамическую память. Для объекта имеем

А для инструмента имеем

Причем инструмент всегда будет иметь единый адрес.

Инструментальный подход реализован в МультиОбероне 1.3.

По инструментальному подходу опубликована статья: "Инструментальный подход к программированию в системе МультиОберон".

Не знаю, есть ли аннотации в других Оберонах, но в A2/ЯОС они заключаются в фигурные, а не квадратные скобки. Также слова NEW и ABSTRACT тоже логично загнать в синтаксис аннотации, чтобы не перегружать смыслами основной синтаксис языка. В A2 это многократно сделано и прекрасно масштабируется по количеству разных аннтоаций. Аннотации даже могут иметь параметры.

Суть предложения понял не совсем (как и концепцию управления данными), но смущает то, что такие инструменты, как Log, имеют динамическую природу в реальных Оберон-системах. Например, при запуске может быть никакой реализации Log (логгирование ничего не делает или рушит систему). После инициализации COM-порта лог начинает писать вывод в COM-порт, а ещё через время может быть включён вывод файл и на графическую консоль. Это требует динамической смены инструмента не в связи с типом данных того клиента, который обращается, а в связи с возрастом системы.

Именно для этого, как мне казалось, Лог сделан именно таким, как он сделан (во всяком случае, в A2, но думаю, что это так и в других Оберонах). По сути дела, через подобные трюки не только реализуется настраиваемость системы и её эволюция во время старта, но и разрешаются циклические зависимости между модулями. Оба применения важны и необходимы. Но я не понял, как это разрешается в рамках статьи, если инструмент всегда имеет один и тот же адрес и привязан к типу клиента.

Была просьба описать подход с помощью mainstream языка. Например, если это так, как ООП-шаблон Stateless(и как следствие Singleton) с оптимизацией — без использования динамической памяти.
А также раскрыть тему персистентности — является ли это частью воплощения Мультиоберона или это нужно обеспечивать полностью самостоятельно?

У каждого инструмента свой адрес. HostLog.hook - один и тот же. А у другого инструмента MyHostLog.hook - другой.

Подход не зависит от языка. Вы можете применять объектное мышление (object thinking), унаследуя определенные рекомендуемые практики (immutable objects, конструкторы, не использование синглетонов и utility-классов). Либо использовать альтернативные подходы. Есть классическое структурное программирование. Есть предложенный инструментальный подход.

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

Персистентность обеспечивается самостоятельно, инструменты не имеют состояния (stateless).

Пытаюсь понять, но не могу. Системная функция TOOL предназначена только для инструмента "Лог"? А если понадобится другая подобная настраиваемая сущность, например, "Дисплей". Вот как раз, какой может быть дисплей - локальный дисплей, который всё рисует с помощью физической видеокарты, или Null дисплей который ничего не рисует, но пишет, что всё успешно нарисовано. Он нужен только для того, чтобы запустить потом VNC сервер. Написано в статье, что функция TOOL всегда возвращает один адрес. Значит, нам нужно два параметра для этой функции, TOOL("Log", приёмник) и TOOL("Display", приёмник), чтобы иметь более одного настраиваемого интерфейса в системе. И далее, если TOOL(x) всегда возвращает один и тот же адрес (так написано в статье), то получается, что его нельзя заменить динамически, о чём я и написал. И здесь у меня опять же непонимание - либо Вы намеренно сузили возможности динамической замены ради контролируемости системы, либо что-то потерялось в ходе сужения.

А, там дальше в статье есть про TOOL с тремя параметрами. Видимо, выбор между Display и Log осуществляется по типу первого параметра. Просто пример, который приведён здесь, на форуме, уж слишком упрощённый. Ну и я не нашёл, как, собственно, определяется, чему равен инструмент. Т.е. каждый инструмент (допустим, Лог), может быть реализован только одним образом? Если так, то зачем он вообще нужен, почему нельзя просто написать несколько процедур? Если же возможно несколько реализаций инструмента, то как выбирается та реализация, которая будет возвращаться функцией TOOL?

А, и про это нашёл. Получается двойная диспетчеризация по "номеру инструмента", с точки зрения ЯП это тип данных инструмента, и как это задаётся тоже нашёл. В общем, как мне сначала и показалось, похоже, что такая особенность лога и дисплея, как возможность их динамической настройки и изменения со временем, здесь утрачена. Вместо неё есть привязка к типу данных. Наверное, можно ввести глобальную переменную "возраст этой системы", и присваивать ей символических наследников разного типа (это не инструменты, но их тоже можно положить в статическую память, т.к. это лишь символы и их смысл - иметь различную идентичность). А уже с этими наследниками ассоциировать разные реализации Лога. И тогда уже глобальная функция Log.String работала бы по-разному в зависимости от возраста системы. Верно я понял?

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

Я бы сказал, что это больше всего похоже просто на реализацию интерфейсов, но с использованием статической памяти для хранения реализаций интерфейса. Если бы можно было размещать некоторые указатели в статической памяти, то эта возможность сама бы упала нам в руки, заодно со многими другими. В лисп-системах для этого есть понятие "purify", которое делает определённые данные псведо-статическими, а также save-image, которое сохраняет образ системы в файл для последующего перезапуска. Псевдо-статические данные не являются корнями при сборке мусора, но никогда не превращаются в мусор.

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

В сухом остатке - пока что нужность процедуры TOOL с одним параметром так и осталась для меня непонятной.

А зачем? Ведь передача object нужна была для передачи контекста, которого у tool просто нет. Или всё-таки есть? Не нужен и дополнительный контейнер процедур do, который был один для разных переменных этого типа, потому что tool и есть такой контейнер — один для всех. Если я всё правильно понял, то наиболее уместным было бы


На мой взгляд, если воплощать такой подход(как я его понял) не как надстройку, а встраивать в язык, то можно было бы делать иначе. Если отталкиваться от того, что предложенная сущность — это не ограниченная запись с методами, а обобщение процедуры, то это могло бы увеличить ясность. Как вариант:

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

Тогда интересно следующее — чем сохранение данных записи-объекта отличается от сохранения данных записи-параметра?

Это похоже на unsafe pointer в Активном Обероне.


А в ECS Oberon-2 есть указатели на переменные.

Да, UNTRACED в Вашем варианте. GC его игнорирует. Но информация о типах есть. И нет экземпляра переменной.