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
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
