Забыл добавить еще один важный момент.
Рассмотрим сборную арку, то есть арку, состоящую из других арок и схемы соединения. В Вире называл такие «сборки» Узлами. Думаю о другом термине, типа над-арка, но пока не придумал, буду называть Узлом.
Так вот, с точки зрения клиента, Узел не должен ничем отличаться от обычной арки. Соответственно, должна быть возможность сформировать «сборный объект», который арка-клиент может преобразовать к протоколу. Виртуальная таблица сборного объекта должна состоять из методов разных арок. Впрочем, как это должно быть устроено, сейчас не важно. Важно только то, что замена арки на Узел не должна приводить к необходимости изменения клиента или настроек схемы.
PS. Если уведомления от блога не доходят, то можно придумать какой-то обход. Например, могу писать о том, что появилась новая запись в VK.
Постоянная ссылка
Спасибо за концепт. Напоминает древний Esterel:
* https://en.wikipedia.org/wiki/Esterel
* https://www.college-de-france.fr/sites/default/files/documents/gerard-berry/UPL681247605558671166_Esterelv7.60_ReferenceManual.pdf
Язык моделирования автоматов, действия и модули (реализующие поведение) компонуются иерархически (вложено) и параллельно, кроме функций взаимодействие через широковещательные сигналы. Используется гибкая, но «замороченная» система интерфейсов для модулей (видимо, по историческим причинам плюс необходимость в трансформации моделей к иным видам): с возможностью инверсии (вход/выход меняются местами), «утиная типизация» для коннекта сигналов (по совпадению имен) плюс «порты» для явной конфигурации и пр. Модель статична.
Динамические автоматы по мотивам Esterel встречаются в языке Ceu:
* http://www.ceu-lang.org
Это академический (или полуакадемический) проект, «реактивное расширение над структурным программированием». Изменена семантика (введено понятие мгновенного реагирования на внутренние события, callback по сути), интерфейсы свернулись до «классических» сигнатур операций. Похоже, что на сайте не обновлена документация по языку. В указанных там публикациях заметно, что процедуры с «синхронными» конструкциями (они же присутствуют и в демо-ролике на старт. странице) трансформировались в классы, нечто вроде «активных объектов». Наблюдается расширение типов и динамическая диспетчеризация (виртуальные вызовы). Память автоматическая без gc, изолирована внутри «объектов» плюс стековая дисциплина.
Этот Ceu ещё больше похож…
Постоянная ссылка
Из интересных находок. Я тут обнаружил аж ДВА направления исследований в ЯП, которые смежны с обсуждаемой темой.
1. Алгебраические эффекты в ФП. Недавно завезли в OCaml, например, т.е. это горячая тема в мире ФП. Как обычно, понять там что-то сложно, если вы не укушены haskell-программистом, но общий смысл такой, что побочные эффекты самых разных видов (а для меня — это интерфейсы!) должны предоставляться «где-то сверху» когда употребляются «где-то в глубине». Как водится, они это всовывают в типы, так что [не]корректность соединения функций сразу видна на этапе компиляции. Как верно замечают в комменртах к статье (https://habr.com/ru/articles/470718/) в мире ООП это просто DI, разве что нужны средства типа Context-oriented programming для проброса интерфейсов сверху вниз без boilerplate.
2. См. ключевые слова «capabilities-beased security», «capability-object languages». Это идеи изоляции и ограничения ввода/вывода и доступа к системным API, о которых мы говорили недавно, ценные с т.з. security. Я пришел к этим же идеям реализации, ища пути с т.з. понятности (comprehensibility?), и тоже заметил, что это работает в т.ч. на security. Идея в том, чтобы нельзя было «взять и прочитать/записать какой-то файл или узел DOM или сокет» если тебе не выдали ссылку/права конкретно на него, и эта цепочка выдачи прав должна легко прослеживаться с самого верха программы. В моем экспериментальном DSL — это просто правило «весь ввод-вывод и эффекты — только через интерфейсы» + правило «все интерфейсы — только от родительского компонента». Вроде примерно то же самое выходит. Можно прочитать (например, тут: https://en.wikipedia.org/wiki/EROS_(microkernel)#Journals) что «Capability systems naturally promote component-based software structure. This organizational approach is similar to the programming language concept of object-oriented programming, but occurs at larger granularity» и это именно то, что мы обсуждаем!
Постоянная ссылка
Добрый день.
Если клиент должен заботиться о том, как «сформировать «сборный объект» и привести его к протоколу», это нарушает инкапсуляцию и принцип подстановки, который вы верно сформулировали.
Я его пересказываю так : компонент предоставляет какие-то интерфейсы, и снаружи не видно как они реализованы — может быть делегированы вложенным компонентам, может быть реализованы императивным кодом, а может быть разобраны на части и разные части одного комплексного интерфейса реализованы по-разному. Если мы меняем способ реализации — клиенты нашего компонента никак не должны это заметить.
Например, вот тут https://github.com/iamhere2/HLCD-Researches/blob/master/ChessApp/src/RustMacros/src/chess_app/console_ui.rs
интерфейс «точка входа консольного приложения» (ConsoleApp) реализован через делегирование дочернему комплоненту, но можно было бы просто сделать метод Run(args) -> Int.
Но у вас протоколы, как я понял, находятся на стороне клиента (утиная типизация), и вот это все несколько усложнняет, я уже не понимаю, как обеспечивать сокрытие реализации без наличия именованных интерфейсов на стороне компонента-сервера :-/
Постоянная ссылка
>Если клиент должен заботиться о том, как «сформировать «сборный объект»
Не клиент (если мы понимаем под ним использующую арку), а разработчик арки (сборной арки) заботится о том, чтобы выставить наружу «разъем» — «сборный объект» с набором методов. Разработчик арки-клиента выставляет свои требования (хочу такие методы) в виде протокола (или протоколов).
>как обеспечивать сокрытие реализации без наличия именованных интерфейсов на стороне компонента-сервера
Интерфейс у арки есть — это набор экспортированных методов. Но он не обязан быть доступен клиенту (программному коду) или человеку, собирающему схему, до работы программы. Интерфейс может быть доступен, тогда семантические проверки могут быть сделаны AOT, а может и не быть доступен.
В любом случае (AOT or JIT) протокол клиента описывает нужные клиенту методы, и эти методы должны быть подмножеством методов арки-сервера.
Постоянная ссылка
Ок, я значит недопонял. Сборный объект просто должен уметь выставить нужные входы, возможно, делегировав их дочерним. Да, тогда одинаково видим.
Постоянная ссылка
Добрый день.
Я тут еще осознал, что то, что мы обсуждаем, в особенности то, что делаете вы, Алексей, весьма похоже на акторную модель.
В Akka и Akka.NET как широко известных реализациях, принята иерархическая структура адресации для компонентов-акторов, формирующая явную схему архитектуры:
https://getakka.net/articles/intro/getting-started/tutorial-1.html
Ну и по классике, акторы могут отправлять сообщения, что весьма динамический способ взаимодействия.
Я думаю, что модель акторов бедновата выразительными средствами. Наверное это помогло добиться каких-то успехов в ее математическом анализе, но вот мне бы хотелось чего-то более выразительного, чем просто «сообщения по адресу». Ну, вы знаете — интерфейсы, все такое. Но как источник идей эта область computer science наверное тоже может послужить.
Постоянная ссылка
> источник идей эта область computer science наверное тоже может послужить
Да, может быть полезно. Но все же, эта полезность в деталях, так как архитектурного взгляда у них нет.