On 3/9/2012 11:48 AM, Jacopo Cappellato wrote:
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)
Exactly.
2) implement a DSL to write OFBiz applications in Java as a series of method
calls to an helper class
No, provide a helper class that developers can use to implement a DSL.
3) the user will then chose the scripting language of his preference and then
will use the DSL to write code
Yes, the developer can choose a scripting language. Whether or not the
scripting language has been extended to a DSL by incorporating the
helper class is a separate issue.
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?
Anything we want. As long as we keep it generic, we are free to
add/remove any scripting language. On the other hard, if we make it all
Groovy-centric, then we have a lot of re-engineering to do if we decide
to make a change.
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.
Again, I think there is some confusion on what a "DSL for OFBiz" means.
If it means we can add OFBiz-specific extensions to an existing
language, then the API can be kept simple.
-Adrian
