Hi Mathieu,
Can you explain hat you want to do exactly? How do these services access the delegator and whatnot? On Sun, Nov 11, 2018 at 5:32 PM Mathieu Lirzin <[email protected]> wrote: > > Hello, > > While I think using Groovy for implementing services is a better choice > than Java, I am not convinced by the rationale of using Groovy DSL > features. Here are the various drawbacks I see: > > - The service DSL breaks the function/method local scoping goodness by > introducing various global variables (parameters, delegator, ...) > > - There is no clear disctinction between services and helper methods > (private/public) > > - When Unit testing a helper method defined in a DSL script, a > cumbersome mechanism for accessing the groovy method is required > > - DSL implicit class context abstraction is leaky, for example it is > hard to understand what is the proper way to define a variable > outside of a method and how to refer to it from this method. > > def foo = "foo" > def barService() { > print foo // => ERROR: No such property: foo for class: ... > } > > IMO DSL features introduce accidental complexity with very little > benefits. Since plain Groovy classes doesn't suffer from the downsides > I described above and preserve the Groovy goodness (map literals, > optional typing, ...), I recommend transitioning from DSL scripts to > classes. > > What do people think? > > Thanks. > > -- > Mathieu Lirzin > GPG: F2A3 8D7E EB2B 6640 5761 070D 0ADE E100 9460 4D37
