If Groovy would support closure-block constructs ("inlining closures"),
this could be overcome without having to resort to writing one's own
macro (which is more effort, especially if you do not already have a
seperate macro module set up in your project). I still think inlining
closures in cases where the closure is in fact used more like a block
construct would be a useful Groovy feature to have*.
As I have said before I use something similar to what Eric is looking
for in my SqlExecutor Groovy Sql wrapper
sqlExecutor.withRollback {
// do some DB changes which will automatically be rolled back at
end of closure / block
}
for tests (as a specialized version of
SqlExecutor#withTransaction(Closure) )
Inlining that would allow me to e.g. use return statements inside the
withRollback block and have them behave as expected, instead of just
leaving the closure.
In Eric's case it would get rid of the Closure creation overhead (which
in my case is not that much of a concern, evidently).
I think we should continue to look for powerful, generally useful
building blocks, that allow programmers to solve a wide range of problems.
If we could add something that would allow for the saving/restoring of a
bunch of variables/fields (maybe along the line of @NamedDelegate), then
it feels like the whole problem could be solved in Groovy without
needing to resort to specialized macros or AST transformations.
(I am not saying using a macro here is inherently bad, just that the
hurdle for most Groovy devs will be considerably higher)
Cheers,
mg
*It could be abused, yes, but so can many others, and one could make it
abundantly clear in the docu that inlining closures is not a silver
bullet, and you should know what you are doing.
On 22/11/2020 15:21, Jochen Theodorou wrote:
On 21.11.20 20:29, Milles, Eric (TR Technology) wrote:
[...]
<zip>
could be a mixin... but if your requirement is to avoid the creation of
additional objects, then this will not work, as the Closure will be
created new every time. And then a macro would be indeed better.
