Есть некий программный пакет П1 с входным языком Я1. Для удобного использования этого пакета я решил расширить его язык. Расширение заключается в добавлении дополнительных режимов к существующим командам языка. Команда в расширенном режиме разворачивается в набор команд на том же входном языке Я1. Алгоритмов генерации таких наборов может быть несколько (назовем их А1,А2,...) Для всего этого я создал dsl на ruby, который максимально близко повторяет синтаксис Я1. Так же реализовал несколько сменных алгоритмов. Все вроде худо-бедно работает.
Сейчас я решил расширить функционал своей поделки т.к. помимо моего любимого пакета П1 существует еще куча пакетов П2,П3,... со своими Я2,Я3,... которые умеют то что не умеет П1. Так же я хочу свои данные на Я2 которые я хочу обработать на П1. Все языки декларативные, по функциональности все достаточно похожи но есть и различия.
Хотел было дописать существующий код, но увы, понял что лучше начать сначала и по правильному
Планируя реализацию я решил что пока ограничусь Я1,Я2,Я3 и парой алгоритмов. Для языков буду создавать их dsl-аналоги ДЯ1..ДЯ3 на ruby (это упрощает разбор синтаксиса). Так же поразмыслив пришел к выводу что количество ДЯ и Я может и не совпадать и вообще это суть разные вещи.
Вопрос
Мой вопрос заключается в том как оптимальнее построить архитектуру приложения с такими требованиями:
1. Из любого из ДЯ1..ДЯ3 получать файл на любом из Я1..Я3 при помощи любого из А1..А2
2. Возможность как можно более безболезненного добавления новых элеметов в систему: нового входного языка(ДЯ), нового выходного языка(Я), нового алгоритма
Я бы смотрел в сторону создания унифицированного кода. Тогда так получается:
Исходный код (любой) → ваш транслятор для него → универсальный код (УК) → транслятор УК в любой код.
Здравствуйте, LeonidV, Вы писали:
LV>Только я насчет алгоритмов не слишком понял.
Предметная область — специфическая разновидность топографии. При съемке на местности снимается 10 или более параметров, а пакеты как правило обрабатывают 3 из них (они все любительские и простенькие).
Например команда из Я1, которая выводит примитив-отрезок: data a b c
На расширенном языке она же, но с остальными данными: data a b c d e f g h
Примеры алгоритмов:
1) вывод отрезка как в Я1 (1 отрезок)
2) вывoд отрезка в виде треугольника (3 отрезка)
3) вывoд отрезка в виде прямоугольника (4 отрезка)
LV>Я бы смотрел в сторону создания унифицированного кода. Тогда так получается: LV>Исходный код (любой) → ваш транслятор для него → универсальный код (УК) → транслятор УК в любой код.
У меня примерно так сейчас и есть, универсальный код лежит во массивах. Алгоритмы его читают и сразу создают конечный код. Поэтому и возникла проблема с добавлением второго выходного языка.
Логично было бы провести трансформацию универсального кода, но алгоритмы сильно завязаны на выходной язык. И в то же время для разных выходных языков могут применяться и одинаковые алгоритмы, т.е. трансформация универсального кода вполне подходит. Как это все оформить архитектурно?
Отдельно хочу спросить как оптимальней хранить универсальный код? Мне моя реализация не нравится.
Здравствуйте, v_su, Вы писали:
_>Предметная область — специфическая разновидность топографии. При съемке на местности снимается 10 или более параметров, а пакеты как правило обрабатывают 3 из них (они все любительские и простенькие).
