Как я уже писал, на следующем этапе движения в светлое будущее, я вижу необходимым разработать и реализовать 3 языка:
- язык описания схемы соединения компонент
- язык разработки компонент
- язык описания пользовательского интерфейса
Задача масштабная, и надо понять, как её разложить на более простые шаги. Самая непонятная задача — это 3). Тут у меня большое белое пятно. С первыми двумя какие-то наметки уже есть, но напрямую использовать наработки из Вира я считаю неверным. Скорее всего язык соединения компонент (СК) будет, по основным конструкциям, примерно таким же, как в Вире (но вовсе не обязательно по синтаксису и семантике). Язык разработки компонент (РК) точно будет существенно отличаться от того, что был в Вире (другие задачи и другое видение).
При этом, если основу Тривиля я нарисовал примерно за день, и большая часть того, что я тогда нарисовал, вошла в язык, то РК я не вижу так ясно, как я видел Тривиль. Значит, надо прототипировать.
- Верите ли вы в любовь с первого взгляда?
- Видите ли, я подслеповат, мне щупать надо…
Вырисовывается такая последовательность:
- Делаю черновой дизайн СК
- Делаю прототип СК (язык и инструмент сборки), имитируя компоненты на Тривиле
- Выявляю требования к РК, делаю черновой дизайн РК
- Делаю компилятор РК, и поддержку исполнения РК с динамической загрузкой
- Проверяю на чем-нибудь существенном по размеру/сложности
- И после этого перехожу к декларативному UI
Как всегда, глаза боятся, надеюсь, что руки делают…
Из чего состоит прототип СК:
- Есть набор «компонент», для простоты это несколько классов на Тривиле, которые статически импортируются
- Есть текстовая Схема, по которой Сборщик создает экземпляры компонент, соединяет их и потом запускает
- Прототип должен показать, что из одних и тех же компонент собираются функционально разные «программы»
- И дать понимание того, что такое компонента, интерфейс компонент и способы их соединения
- Отсюда должны следовать требования к РК и набору конструкций РК
Если сразу делать динамическое подключение компонент, то задача становится очень объемной, поэтому тренироваться в прототипе буду на имитации динамики. Впрочем, имитацию можно сделать более реалистичной, если часть компонент подключать через динамические библиотеки (DLL/SO) — не уверен, что в этом есть смысл.
Итого, шаги 1 и 2 примерно видны, можно двигаться.
Постоянная ссылка
Добрый день.
> Есть набор «компонент», для простоты это несколько классов на
> Тривиле, которые статически импортируются
> Есть текстовая Схема, по которой Сборщик создает экземпляры
> компонент, соединяет их и потом запускает
У меня возникают смутные сомнения от чтения этих нескольких тезисов. А именно:
1. Разве несколько уже соединенных компонент — это не компонент?
2. Я же могу соединить А1+А2+А3 в A, B1+B2+B3 в B, и затем соединить A+B? Вспоминаем также давний разговор про А-компоненты (которые собираются) и D-компоненты (которые пишутся более традиционным способом)
3. А тогда что такое Схема, если это не A-компонент? Имхо, это понятие становится лишним
4. Когда кто-то создает экземпляр А-компонента, должен ли он знать его устройство, или сам А-компонент как Схема знает свое устройство, но только на один уровень вглубь, до компонентов, из которых состоянит, которые как-то соединены между собой и еще подключены к зависимостям?
4. Не является ли программа на верхнем уровне просто А-компонентом, который подключен к зависимостям типа INetIO, IFileIO и IConsoleIO, IWindowsGUI, etc?
Ну и засим предлагаю посмотреть на результаты моих экспериментов с компонентным подходом с DSL на макросах Rust:
Компонент-консольное приложение:
https://github.com/iamhere2/HLCD-Researches/blob/master/ChessApp/src/RustMacros/src/chess_app.rs
Один из компонентов следующего уровня:
https://github.com/iamhere2/HLCD-Researches/blob/master/ChessApp/src/RustMacros/src/chess_app/console_ui.rs
Это работающий код, если что. Конечно, приложение недоделанное, но принцип показан и это работает.
ИМХО, вполне «схемный» подход. Ничего кроме схемы на верхних двух уровнях. Чисто А-компоненты.
Конечно, иерархический подход. Только иерархия дает борьбу со сложностью. Не одна «Схема», а на каждом узле деревап — схема. И Rust очень помогает с его иерархическими модулями с ограниченной видимостью, разложенными по папочкам и подпапочкам
Ну и наконец, последняя ассоциация — componen diagram в UML. По идее эти А-компоненты 1-в-1 тупо отрисовываются в componen diagram и эта диаграмма остается на каждом узле простой.
https://github.com/iamhere2/HLCD-Researches/tree/master/ChessApp/dgm/Images/AsyncFlow
Но, кстати, новые интересные вопросы возникают про структуры данных, и на каких уровнях они должны определяться в какой детальности, в каких местах оставаться динамическими/обобщенными. Тут много неясного еще пока.
Постоянная ссылка
Ответ здесь
Постоянная ссылка
На счет п.3 предлагаю посмотреть идеи из slint ( https://slint.dev/releases/1.1.0/docs/slint/ ). На мой взгляд, реализация slint в целом интересная получается.