OberonCore

Библиотека  Wiki  Форум  BlackBox  Компоненты  Проекты
Текущее время: Воскресенье, 23 Июнь, 2024 10:33

Часовой пояс: UTC + 3 часа




Начать новую тему Ответить на тему  [ Сообщений: 14 ] 
Автор Сообщение
 Заголовок сообщения: Инструментальный подход
СообщениеДобавлено: Среда, 03 Апрель, 2024 18:10 

Зарегистрирован: Вторник, 01 Март, 2011 09:34
Сообщения: 589
Откуда: Москва
Выработалась концепция инструментального подхода. Если совсем просто, то инструмент - это указатель на объект без полей данных. Как Log.Hook. Но для такого инструмента не требуется выделять динамическую память. Для объекта имеем
Код:
Hook = POINTER TO RECORD (...) END;
VAR h: Hook;
NEW(h);

А для инструмента имеем
Код:
RESTRICT +TOOL;
Hook = POINTER TO RECORD [tool] (...) END;
VAR h: Hook;
TOOL(h);

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

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


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Инструментальный подход
СообщениеДобавлено: Среда, 03 Апрель, 2024 18:13 

Зарегистрирован: Вторник, 01 Март, 2011 09:34
Сообщения: 589
Откуда: Москва
По инструментальному подходу опубликована статья: "Инструментальный подход к программированию в системе МультиОберон".


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Инструментальный подход
СообщениеДобавлено: Четверг, 04 Апрель, 2024 15:39 

Зарегистрирован: Понедельник, 11 Сентябрь, 2017 13:23
Сообщения: 1566
Цитата:
Интерфейс являет некритическим


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

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

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


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Инструментальный подход
СообщениеДобавлено: Пятница, 05 Апрель, 2024 14:18 

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


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Инструментальный подход
СообщениеДобавлено: Суббота, 06 Апрель, 2024 08:30 

Зарегистрирован: Вторник, 01 Март, 2011 09:34
Сообщения: 589
Откуда: Москва
budden писал(а):
инструмент всегда имеет один и тот же адрес и привязан к типу клиента.

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


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Инструментальный подход
СообщениеДобавлено: Суббота, 06 Апрель, 2024 09:11 

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

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

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

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


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Инструментальный подход
СообщениеДобавлено: Суббота, 06 Апрель, 2024 14:36 

Зарегистрирован: Понедельник, 11 Сентябрь, 2017 13:23
Сообщения: 1566
Дмитрий Дагаев писал(а):
budden писал(а):
инструмент всегда имеет один и тот же адрес и привязан к типу клиента.

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


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


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Инструментальный подход
СообщениеДобавлено: Суббота, 06 Апрель, 2024 14:40 

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


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Инструментальный подход
СообщениеДобавлено: Суббота, 06 Апрель, 2024 14:54 

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

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


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Инструментальный подход
СообщениеДобавлено: Суббота, 06 Апрель, 2024 14:56 

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

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


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Инструментальный подход
СообщениеДобавлено: Суббота, 06 Апрель, 2024 14:59 

Зарегистрирован: Понедельник, 11 Сентябрь, 2017 13:23
Сообщения: 1566
В сухом остатке - пока что нужность процедуры TOOL с одним параметром так и осталась для меня непонятной.


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Инструментальный подход
СообщениеДобавлено: Суббота, 06 Апрель, 2024 16:00 

Зарегистрирован: Четверг, 08 Май, 2008 19:13
Сообщения: 1449
Откуда: Киев
Дмитрий Дагаев писал(а):
В качестве реализации инструментального подхода можно использовать Suite, как Вирт в Обероне
Код:
object.do.Method(object, params);
А зачем? Ведь передача object нужна была для передачи контекста, которого у tool просто нет. Или всё-таки есть? Не нужен и дополнительный контейнер процедур do, который был один для разных переменных этого типа, потому что tool и есть такой контейнер — один для всех. Если я всё правильно понял, то наиболее уместным было бы
Код:
object.Method(params)


Дмитрий Дагаев писал(а):
Разумеется, инструменты и функцию TOOL можно использовать в Обероне-07, если возникнет интерес (например, у разработчика компилятора Восток).
На мой взгляд, если воплощать такой подход(как я его понял) не как надстройку, а встраивать в язык, то можно было бы делать иначе. Если отталкиваться от того, что предложенная сущность — это не ограниченная запись с методами, а обобщение процедуры, то это могло бы увеличить ясность. Как вариант:
Код:
MODULE Log;
 TYPE
  T* = PROCEDURES
    String (IN str: ARRAY OF CHAR);
    Ln
  END;
END Log.

MODULE NoLog; IMPORT Log;

 PROCEDURE String (IN str: ARRAY OF CHAR); END String;
 PROCEDURE Ln; END Ln;

 PROCEDURES (Log.T) Do*;
  .String = String;
  .Ln = Ln;
 END Do;

END NoLog.

MODULE Use; IMPORT Log, NoLog, SomeLog;
 VAR log: Log.T;
  string: PROCEDURE (IN str: ARRAY OF CHAR); ln: PROCEDURE;

 PROCEDURE Go*;
 BEGIN
  log.String("И так можно"); log.Ln;
  string("И эдак"); ln
 END Go;

BEGIN
 IF SomeLog.Supported
 THEN log := SomeLog.Do
 ELSE log := NoLog.Do
 END;
 string := log.String; ln := log.Ln
END Use.

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

Дмитрий Дагаев писал(а):
Персистентность обеспечивается самостоятельно, инструменты не имеют состояния (stateless).
Тогда интересно следующее — чем сохранение данных записи-объекта отличается от сохранения данных записи-параметра?


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Инструментальный подход
СообщениеДобавлено: Воскресенье, 05 Май, 2024 10:02 

Зарегистрирован: Пятница, 11 Январь, 2019 19:26
Сообщения: 295
Откуда: Russia
Это похоже на unsafe pointer в Активном Обероне.
Код:
TYPE
    Hook = POINTER { UNSAFE, UNTRACED } TO HookRec;
    HookRec= RECORD
      PROCEDURE P*; END P;
    END;

    PROCEDURE TOOL*(): Hook;
    BEGIN
        RETURN ADDRESS OF h
    END TOOL;

VAR h: HookRec;


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


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Инструментальный подход
СообщениеДобавлено: Понедельник, 06 Май, 2024 08:54 

Зарегистрирован: Вторник, 01 Март, 2011 09:34
Сообщения: 589
Откуда: Москва
Да, UNTRACED в Вашем варианте. GC его игнорирует. Но информация о типах есть. И нет экземпляра переменной.


Вернуться к началу
 Профиль  
 
Показать сообщения за:  Поле сортировки  
Начать новую тему Ответить на тему  [ Сообщений: 14 ] 

Часовой пояс: UTC + 3 часа


Кто сейчас на конференции

Сейчас этот форум просматривают: нет зарегистрированных пользователей и гости: 1


Вы не можете начинать темы
Вы не можете отвечать на сообщения
Вы не можете редактировать свои сообщения
Вы не можете удалять свои сообщения
Вы не можете добавлять вложения

Найти:
Вся информация, размещаемая участниками на конференции (тексты сообщений, вложения и пр.) © 2005-2024, участники конференции «OberonCore», если специально не оговорено иное.
Администрация не несет ответственности за мнения, стиль и достоверность высказываний участников, равно как и за безопасность материалов, предоставляемых участниками во вложениях.
Без разрешения участников и ссылки на конференцию «OberonCore» любое воспроизведение и/или копирование высказываний полностью и/или по частям запрещено.
Powered by phpBB® Forum Software © phpBB Group
Русская поддержка phpBB