Comments 12
UFO just landed and posted this here
Вы верно заметили. Это обычный Kotlin код. Если быть точнее, это набор стандартных конструкций языка, благодаря которым мы строим проблемно-ориентированный язык, который специфичен для нашего проекта. Чем в вашем понимании «проектно специфичный фреймворк» отличается от DSL?
А где сам язык, который вы построили? Что он может, чем он удобен, в конце концов?
Я вообще не уверен, что хаки с синтаксическим сахаром и набор утилитных функций (которые не похожи на код, но компилируются! вот прикольно!) — это уже DSL.
Я вообще не уверен, что хаки с синтаксическим сахаром и набор утилитных функций (которые не похожи на код, но компилируются! вот прикольно!) — это уже DSL.
А где сам язык, который вы построили?
Пример использования языка вы увидите в разделе «Пример финального результата»
Код доступен на GitHub по ссылкам в статье.
Я вообще не уверен, что хаки с синтаксическим сахаром и набор утилитных функций (которые не похожи на код, но компилируются! вот прикольно!) — это уже DSL.
Использование элементов языка общего назначения для получения специфичных для решаемой задачи конструкций — это один из вариантов построения DSL. Вы можете убедиться в этом сами по ссылке и в других источниках по запросу «internal domain-specific language»
Возможно, в данном случае мы видим пример EDSL
Согласитесь, удобно описать сложный тест-кейс в виде кода
Альтернатива — многоэтажные if/case которые не всегда с первого раза прочтешь.
Согласитесь, удобно описать сложный тест-кейс в виде кода
MyLittleDSL
schedule {
data {
startFrom("08:00")
subjects("Russian",
"Literature",
"Algebra",
"Geometry")
student {
name = "Ivanov"
subjectIndexes(0, 2)
}
Альтернатива — многоэтажные if/case которые не всегда с первого раза прочтешь.
Да я понимаю. Spock Framework я сам пользовался для написания unit тестов, синтаксис куда более легковесный, чем в обычном JUnit (хотя под капотом используется именно он).
Я просто не понимаю помпы, с которой подается статья. Мы все делаем удобный для себя набор абстракций и mini-API для решения каких-то частных задач. Называть такой набор DSL и жаловаться на ограничения языка — ну это уж перебор. Хочешь свой язык и чтобы тебя ничего не ограничивало — ANTLR в руки :-)
Я просто не понимаю помпы, с которой подается статья. Мы все делаем удобный для себя набор абстракций и mini-API для решения каких-то частных задач. Называть такой набор DSL и жаловаться на ограничения языка — ну это уж перебор. Хочешь свой язык и чтобы тебя ничего не ограничивало — ANTLR в руки :-)
Далеко не все делают для себя «удобный mini-API». Kotlin DSL это легкий способ и API в терминах предметной области получить, и сил затратить мало, так еще и такой подход полностью совместим с вашим Java кодом. Не стоит принимать «минусы» как жалобу, я хочу, чтобы у читателя было более объективное представление об инструменте до начала его использования. А про ANTLR для тестирования Java кода это вы отлично пошутили.
UFO just landed and posted this here
Не шутил и не говорил такого. ANTLR — отдельно, Spock Framework со своим аккуратным синтаксисом — отдельно.
DSL — это, как мне кажется, чуть иная вещь, нежели библиотека/фреймворк под задачу. Это все таки — язык, со своим синтакисом и правилами.
Куда лучше рассматривать на роль DSL языки в Racket(например, тот же Scribble — DSL для оформления документов)
Куда лучше рассматривать на роль DSL языки в Racket(например, тот же Scribble — DSL для оформления документов)
Вот тут пример DSL для языка разметки HTML, от разработчиков. На основе описанных здесь типа-безопасных билдеров
Непростая, но очень хорошая статья. При этом DSL'ы я не переношу, поскольку обычно они сводятся к «языку внутри языка», который понимает хорошо еще, если тот, кто его написал. Но примеры разобраны нетривиальные, и разобраны очень хорошо.
Sign up to leave a comment.
Kotlin DSL: Теория и Практика