Что разделяет DSL Ruby от обычного API
Свойство границ является толщиной, точно так же, как поле и дополнение, таким образом, можно сделать Границу = "2,0,2,2" для получения границы 2 везде кроме вершины.
6 ответов
When you use an API you instantiate objects and call methods in an imperative manner. On the other hand a good DSL should be declarative, representing rules and relationships in your problem domain, not instructions to be executed. Moreover ideally DSL should be readable and modifiable by somebody who is not a programmer (which is not the case with APIs).
Also please keep in mind the distinction between internal and external DSLs.
- Internal domain specific language is embedded in a programming language (eg. Ruby). It's easy to implement, but the structure of the DSL is dependent on the parent language it is embedded in.
- External domain specific language is a separate language designed with the particular domain in mind. It gives you a greater flexibility when it comes to syntax, but you have to implement the code to interpret it. It's also more secure, as the person editing domain rules doesn't have access to all the power of the parent language.
DSL (предметно-ориентированный язык) - это сильно раздуваемый термин. Если вы просто используете подмножество языка (скажем, Ruby), чем он отличается от исходного? Ответ - нет.
Однако, если вы выполните некоторую предварительную обработку исходного текста, чтобы ввести новый синтаксис или новую семантику, не найденную в основном языке, тогда у вас действительно есть новый язык, который может быть предметно-зависимым .
Комбинация режима поэзии Ruby и перегрузки операторов действительно дает возможность наличия чего-то, что одновременно является законным синтаксисом Ruby и разумным DSL.
И продолжающееся ухудшение, связанное с XML, действительно показывает, что, возможно, простой DSL, встроенный во все эти файлы конфигурации, не был полностью ошибочным ...
Основное отличие заключается в том, что код АОП включен в вашу программу
" линия между ними тонкая. Превратить настраиваемый набор объектов в DSL просто, добавив один метод, запускающий файл сценария в правильном контексте.
По сути, это одно и то же. DSL обычно реализуются с помощью обычных языковых механизмов в Ruby, так что технически они все API.
Однако для того, чтобы люди распознали что-то как DSL, обычно заканчивается добавлением того, что выглядит как декларативные операторы к существующим классам. Что-то вроде валидаторов и объявлений отношений в ActiveRecord.
class Foo << ActiveRecord::Base
validates_uniqueness_of :name
validates_numericality_of :number, :integer_only => true
end
выглядит как DSL, а следующее - нет:
class Foo <<ActiveRecord::BAse
def validate
unless unique? name
errors.add(:name, "must be unique")
end
unless number.to_s.match?(/^[-]?\d$/)
errors.add(:number, "must be an integer")
end
end
end
Они оба будут реализованы с помощью обычного кода Ruby. Просто один выглядит так, будто у вас есть классные новые языковые конструкции, а другой кажется довольно заурядным (и излишне многословным и т.д. и т.п.)
Для меня разница между DSL и API заключается в том, что DSL может быть, по крайней мере, понят (и проверен), если он не написан как подъязык Ruby кем-то в этой области.
Например, у вас могут быть финансовые аналитики, пишущие правила для приложения для торговли акциями на Ruby DSL, и им никогда не придется знать, что они используют Ruby.