Tue Feb 21 17:44:20 HKT 2017
A paper show the evolution of a DSL - http://www.mockobjects.com/files/evolving_an_edsl.ooplsa2006.pdf
A stock trading order example of DSL - http://debasishg.blogspot.com[..]05/designing-internal-dsls-in-scala.html
What is the difference between API / DSL if we don't write a parser for our language? From Martin Fowler's blog - http://martinfowler.com/bliki/DslReadings.html , it is mentioned:
Piers Cawley makes the point that a key characteristic of DSLs is their narrow focus on a domain.I think this is a very good summary, usually if most of the APIs are getXXX() , setXXX(), loadXXX() , createXXX() ........ Then we mostly design APIs that expose low level detail to the API user to work on, which, is work but user probably work nicer if we can come up with language like API that allow users to do their work in more descriptive level.
I think if API design like that usually it will reduce the code duplication, what ever real duplication or conceptual duplication. It probably already apply "Tell, don't ask" style - http://c2.com/cgi/wiki?TellDontAsk
A discussion about applying "Tell, don't ask" which lead to message passing architecture - http://beautifulcode.oreillynet.com[..]07/10/do_messages_want_to_be_asynchr.php
And other discussion about "Tell, don't ask"
One good sample with explaination -
Few links - http://dreamhead.blogbus.com/logs/17667876.html
From CRUD to DDD - http://www.udidahan.com[..]2/15/from-crud-to-domain-driven-fluency/
I like this: "XML abuse reduction (conducting an “XML Intervention”)" - http://www.lostechies.com[..]ps-internal-dsl-draft-outline-notes.aspx
DSL maybe the result of encapsulation - http://dreamhead.blogbus.com/logs/214225975.html
Excellent implementation of extending java yourself - http://www.infoq.com/presentations/JetBrains-MPS-DSL http://www.infoq.com/presentations/JetBrains-MPS-DSL-2
How DSL method named - http://tech.pro[..]he-java-fluent-api-designer-crash-course
(google search) (amazon search)