+972 52-548-6969
Building Domain Specific Languages in BooChapter 9 TOC
time to read 2 min | 201 words
Thoughts?
- Starting from a stable origin
- Planning our DSL's versioning story
- Implications of modifying the DSL Engine
- Implications of modifying the DSL API and Model
- Implications of modifying the DSL Syntax
- Implications of modifying the DSL Environment
- Regression Test Suite
- Versioning cut off point - where to apply versioning concerns
- Versioning strategies:
- Abandon Ship Strategy
- Glacial Change Strategy
- Additive Change Strategy
- Tower of Babel Strategy
- Runtime Adapter Strategy
- Compilation Adapter Strategy
- Auto Modification Strategy
- Self Modification Strategy
- Versioning best practices:
# actual content - Closed world
- Regression test suite
More posts in "Building Domain Specific Languages in Boo" series:
- (29 Jul 2008) Chapter 9 TOC
- (17 Feb 2008) Available for early access
Comments
That's a lot of versioning strategies to discuss.
I am curious to your bullet point on Implications of modifying the DSL Environment. What do you mean by environment in this context? When I think of environment I usually think of concerns that should be abstracted from the DSL such as data stores where changing them should not affect the DSL.
Nathan,
Yes, but a lot of them are really simple. Abandon ship == no versioning, for example.
Environment in this case refer to the naming convention, the order in which the are executed, how do you select what to execute, etc.
Ah ok, that makes sense. Looking forward to the next chapter of the book!
Comment preview