Part 2 & 3
- 章节名：Part 2 & 3
- 2013-05-19 22:37:00
Internal DSLs fall into two categories: Embedded(Smart API, Reflective, Typed embedded) & Generative(Compile-time , runtime). Embedded DSLs: patterns in metaprogramming： + Implicit context and Smart APIs: - define the implicit context: Ruby(instance_eval) and Groovy(with) can also build the implicit context declaration, making DSL more readable. - use smart api, Manage side effect be out of abstraction, using block to make side effect. + Reflective metaprogramming with dynamic decorators as Mix-in: The Decorator design pattern is used to add functionalities to objects dynamically during runtime. Ruby `extend` module would make DSL more expressive. (May be the technique will cause type safety and performance problem.) + Reflective metaprogramming with builders. Embedded DSLs: patterns with typed abstractions: It's using commonly in static typed language. Use Higher-order functions as generic abstractions. Remember set enough type constraint in model domain logic! Generative DSLs: boilerplates for runtime generation: + Ruby metaprogramming for concise DSL design (like Rails active record validates_*) + using class methods to abstract validation logic + mixin for dynamic method generation Generative DSLs: macros for compile-time code generation Making DSLs concise with dynamic typing: non-programmer can at least **understand** domain semantics. Ruby/Groovy/Clojure is good at this. + enhance readability: without typing annotation! more succinct syntax. + duck typing + metaprogramming + write an interpreter to generate from string to code. Anatomy of an external DSL: DSL script -> Parser -> Semantic model The role of a parser in designing an external DSL: + YACC + Lex -> C + Bison + Flex -> C++ + ANTLR -> Java, C, C++, Python, and Ruby. + Coco/R
Design the lexical analyzer: specify lexer rules either inline with the grammar specification or as a separate file Design the grammar rules: also defined in a separate file followed the EBNF notation.ANTLRWorks is a gui-based interpreter env to help run sample DSL scripts. Embeding foreign code as a custom actions, populate the semantic model. Building the parser module: wrap it up. The mature evolution of a DSL: + Versioning your DSL. write a simple note when fix bug or introduce new features. Make sure handling backward compatibility, Catering to specific user needs + Smoother evolution of DSL: + Implicit context for better version evolution + Automatic transformation for backward compatibility + A DSL facade can address a lot of versioning problems: decouple dsl wrapper and base abstractions + Follow the principles of **well-designed abstractions**.
大句哥哥对本书的所有笔记 · · · · · ·
Domain separate into problem domain and solution domain. The problem domain is closed t...
Part 2 & 3
说明 · · · · · ·