Здравствуйте, VladD2, Вы писали:

VD>В сотый раз повторяю: главное в ДСЛ-е — модель.

Да хоть в двухсотый. Обоснования будут?

AVK>>Пусть это будет не совсем корректное решение, мне интересно именно на идею посмотреть.

VD>Идею чего?

DSL для такого домена

VD>Ну, предположим можно придумать DSL который бы позволил бы описать некие правила контроля конкретного документа. Что-то вроде:
VD>

VD>Sum > 10000 => Operator mast be Supervisor 
VD>Client is PreferredPartner => UsePrice(3)
VD>

VD>Далее помещаем эти правила в файл и позволяем пользователям изменять его. Ну, и используем эти правила при сохранении документа.

Ты опять скатываешься на реализацию? Как эти правила опишут логику наподобие той, что приведена в моем примере?

AVK>>Если ьы мне был интересен DSL для конфигураций, я бы так и написал.

VD>А нет никакой разница для чего ДСЛ.

Кому нет никакой разницы? Лично мне разница есть.

VD> Проме того почти все ДСЛ используются для конфигурации. Скажем грамматика — это конфигурация для парсера. Описание КА — это конфигурация для машины состояний. Бизнес-правила — это конфигурация для движка проверки бизнес-правил.

Это софистика

VD>Выше я привел пример гипотетических бизнес-правил

Совершенно непонятный. При этом куча подробностей про файлы и моменты сохранения.

VD>. Чтобы привести аналог твоему импертивному коду мне нужно изучить вашу модель.

Я до сих пор не понимаю, о чем речь.

AVK>>Так укажи на ужасы в приведенном коде. Именно их я и хочу обсудить.

VD>Ужасы заключается в том, что в коде моного деталей реализации не относящихся к делу.

Каких именно? Конкретно.

VD> Куча приведений типов. Вызовов АПИ и т.п.

Нет там никакой кучи.

VD> Я чую, что большая часть из приведенного лишняя.

Кроме твоего чутья — есть что нибудь, что можно обсуждать?