On Mar 9, 2012, at 12:28 PM, Adrian Crum wrote: > I'm not suggesting that we extend the DSL for any language. I'm suggesting > the opposite - keep it generic so all languages can use it. > > I'm having a hard time understanding the push back on this. All I'm > suggesting is that we make the DSL a Java interface/class instead of a Groovy > script so the DSL can be reused in other scripting languages. Is there > something fundamentally wrong with that idea that I'm not understanding?
Adrian, no there is nothing wrong but I think we are not understanding each other's vision and goal. I see the work I am doing like a small "plugin" to add to Groovy a few things to make it a perfect language for OFBiz applications (like Minilang). This is similar to the concept of creating some custom freemarker transforms to simplify the creation of pages. So to me the logical step is: 1) select the language that is closest to what we need (or create one, like Minilang) 2) add to it what is missing (this is my small DSL) 3) then use it The effort I am doing is to see if Groovy + a small DSL can be a valid choice for the future of OFBiz. When this effort is done, if you (or anyone else) will see a potential to reuse the same DSL for other scripting languages, I would be more than happy to see it converted in a language independent way (this would be a trivial effort). What (I think) you are proposing is: 1) make OFBiz framework independent from any specific scripting language (apart from Java) 2) implement a DSL to write OFBiz applications in Java as a series of method calls to an helper class 3) the user will then chose the scripting language of his preference and then will use the DSL to write code What I don't see in your plan is what we want to do with the existing "applications" code and new code that will come: continue with Minilang, switch to Groovy, use a mix of languages? If my interpretation of your vision is correct, I have also some doubts about #2: the risk is that we implement a big api to do everything we think a potential user of an unknown language would need; the risk is that we loose the advantages of each specific language. Jacopo
