Building dsl using groovy

Editor's Notes

• #3: A domain-specific language (DSL) is a computer language specialized to a particular application domain. This is in contrast to a general-purpose language (GPL), which is broadly applicable across domains. There is a wide variety of DSLs, ranging from widely used languages for common domains, such as HTML for web pages, down to languages used by only one or a few pieces of software, such as Emacs Lisp for GNU Emacs and XEmacs. DSLs can be further subdivided by the kind of language, and include domain-specific markup languages, domain-specific modelinglanguages (more generally, specification languages), and domain-specific programming languages. Special-purpose computer languages have always existed in the computer age, but the term "domain-specific language" has become more popular due to the rise of domain-specific modeling. Simpler DSLs, particularly ones used by a single application, are sometimes informally called mini-languages. https://softwareengineering.stackexchange.com/questions/80389/can-css-be-considered-a-dsl
• #6: We all know the English meaning of the word fart, but did you know that fartmeans speed in Danish, Norwegian, and Swedish? If that doesn’t make you snicker enough, the words for speed bump in each language are fartbump, fartshump, and farthinder.
• #10: The code is written in a behaviour style, which is closer to English than to programming language code The class has clear sections annotated by labels (given: and expect:) that clearly identify the purpose of the code statements they contain Each label has a comment in the same line that provides a brief description of the business logic There are no “assert” methods (like JUnit). The code is much more compact.
• #12: The code is written in a behaviour style, which is closer to English than to programming language code The class has clear sections annotated by labels (given: and expect:) that clearly identify the purpose of the code statements they contain Each label has a comment in the same line that provides a brief description of the business logic There are no “assert” methods (like JUnit). The code is much more compact.
• #14: show = { println it } square_root = { Math.sqrt(it) } def please(action) { [the: { what -> [of: { n -> action(what(n)) }] }] }
• #15: @TypeChecked - type checking @DelegatesTo - goal of this annotation is to solve both the documentation issue, that will let your IDE know about the expected methods in the closure body, and it will also solve the type checking issue, by giving hints to the compiler about what are the potential receivers of method calls in the closure body.
• #21: The Script class provides base support for integration with your application through the Binding object, as illustrated in this example:
• #23: Whether you are using groovyc to compile classes or a GroovyShell, for example, to execute scripts, under the hood, a compiler configuration is used. This configuration holds information like the source encoding or the classpath but it can also be used to perform more operations like adding imports by default, applying AST transformations transparently or disabling global AST transformations.