Как переводчик использует DSL? - PullRequest
Новая
       48

Как переводчик использует DSL?

2 голосов
/ 05 июля 2011

Я использую переводчик для своего домена, а не компилятор (несмотря на производительность). Я изо всех сил пытаюсь понять некоторые концепции, хотя:

Предположим, у меня есть DSL (в стиле XML) для игры, чтобы разработчики могли легко создавать объекты: 

<building>
  <name> hotel </name>
  <capacity> 10 </capacity> 
</building>

Сценарий DSL анализируется, что происходит?

Выполняет ли он существующий метод для создания нового здания? Как я понимаю, это не просто преобразование DSL в язык более низкого уровня (так как тогда его нужно будет скомпилировать).

Может ли кто-нибудь описать, что интерпретатор будет делать с результирующим разобранным деревом?

Спасибо за вашу помощь.

1 Ответ

3 голосов
/ 05 июля 2011

Многое зависит от ваших конкретных деталей приложения. Например, требуются ли name и capacity? Я собираюсь дать довольно общий ответ, который может быть немного излишним.

Предположения:

  1. Все вложенные свойства являются необязательными
  2. Есть много вложенных свойств, возможно различной глубины

Это предлагает две идеи: структурировать ваш интерпретатор как анализатор рекурсивного спуска и использовать своего рода конструктор для ваших объектов. В вашем конкретном примере у вас будет BuildingBuilder, который выглядит примерно так (на Java): 

public class BuildingBuilder {
  public BuildingBuilder() { ... }
  public BuildingBuilder setName(String name) { ... return this; }
  public BuildingBuilder setCapacity(int capacity) { ... return this; }
  ...
  public Building build() { ... }
}

Теперь, когда ваш парсер встречает элемент building, используйте BuildingBuilder для постройки здания. Затем добавьте этот объект в любой контекст, к которому применяется DSL (city.addBuilding(building)).

Обратите внимание, что если name и capacity являются исчерпывающими и требуются всегда, вы можете просто создать здание, передав два параметра напрямую. Вы также можете построить здание и установить свойства напрямую, как встречается, вместо использования компоновщика (шаблон компоновщика удобен, когда у вас много свойств, и указанные свойства являются неизменяемыми и необязательными).

Если это не объектно-ориентированный контекст, вы в конечном итоге реализуете какую-то функцию buildBuilding, которая принимает текущий контекст и внутренний xml строительного элемента. По сути, вы создаете парсер рекурсивного спуска вручную с помощью библиотеки xml, обеспечивающей фактический анализ отдельных элементов.

Как бы вы ни реализовывали это, вы, вероятно, по достоинству оцените прямое семантическое сопоставление между элементами xml в вашем DSL и методами / объектами в вашем интерпретаторе.

...