Okay, well it seems I am not able to articulate the advantage of keeping
things generic and extensible - so I will stop trying.
-Adrian
On 3/9/2012 1:16 PM, Jacopo Cappellato wrote:
On Mar 9, 2012, at 12:59 PM, Adrian Crum wrote:
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.
I really don't see how using a Groovy specific DSL for OFBiz would make the
system more Groovy-centric than using Groovy with a generic/general purpose
helper class.
OFBiz (I mean the applications, not the framework) will become Groovy-centric
if and when we will decide to use Groovy as the primary language to implement
their services/events/scripts; that will be the big decision; the fact that all
the Groovy services/events/scripts will mostly use a small DSL well suited to
be integrated in Groovy to extend its language will actually make it easier for
us to migrate out of Groovy:
1) convert the DSL class (100 lines of code?) into a generic helper class well
suited for the new language (or discard it completely if the new language will
come with the features we need ootb)
2) convert all the Groovy services/events/scripts to the new language
The big effort will be #2 and not #1 and we are now discussing about #1.
Jacopo
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
