> On Mar 9, 2012, at 10:03 AM, Adrian Crum wrote: >> Another advantage of this approach is the syntax remains the same across >> languages.
I also have some doubts that a language independent DSL would be very useful: the main concept is to extend the language of your preference in a tr For example, in order to copy contents of maps from map to map in Groovy you can do something like: lookupFieldMap = parameters.subMap(['inventoryItemId', 'productId']) so for Groovy a utility method to transfer items from map to map would not be needed; but in another (less powerful) language it may be useful to have. Since we do not know what language the user will choose, it would be difficult to predict the useful methods in our DSL... and we may end up implementing a new language that is "language independent"; I want to avoid this and simply add the minimal amount of code to complete a specific language very powerful for what we need in OFBiz applications. A (super lightweight) DSL, specific to the language chosen by the community for the OFBiz applications, is the best choice in my opinion. Jacopo
