I have never wanted to embed a Closure obj in a GString, but the behavior is
definitely a bit unexpected.
I must admit that I feel that Groovy features like being able to iterate over
null, or that an empty collection is Groovy-true are more of a problem imho. I
have never had any application for the latter, but have a lot of code where I
have to say
final cols = colsIn != null ? colsIn : defaultCols()
instead of just
final cols = colsIn ?: defaultCols()
Btw has an ?= operator ever been suggested, which assigns the RHS iff the LHS
has value null ? If it where also supported for assigning default parameter
values one could do:
void foo(final Columns cols ?= defaultCols(), String s) { s ?= defaultString()}
This would allow to pass in null as parameter value which is passed through
several calls without the need to duplicate e.g. the cols parameter default
value in method definitions, and elegantly assign the default value in the last
method called...
-------- Ursprüngliche Nachricht --------Von: Paul King <[email protected]>
Datum: 22.12.17 00:25 (GMT+01:00) An: [email protected] Betreff: Re:
G-String embedded Closure calling bug?
Or change the last two lines a little more:
println("XX${o2}YY${o2(42)}ZZ$o2") // *42\n*XX\n*XXYY1ZZ\nXXYY1ZZassert
triggered == 4
It looks weird to me but perhaps there was a reason to it?
On Fri, Dec 22, 2017 at 9:20 AM, Paul King <[email protected]> wrote:
I suspect this is intentional but was before my time. Try this also:
int triggered = 0def o1 = { -> triggered++ }def o2 = { println '*' + it;
triggered++ }
println(o1) // ConsoleScript11$_run_closure1@xxxxxxxxprintln(o2) //
ConsoleScript11$_run_closure2@yyyyyyyy
assert triggered == 0println("xyzzy$o1") // xyzzy0assert triggered ==
1println("XX${o2}YY${o2(42)}ZZ") // *42\n*XX\nXXYY1ZZassert triggered == 3
On Fri, Dec 22, 2017 at 8:20 AM, Nathan Harvey <[email protected]> wrote:
Take the following code:
int triggered = 0
def o = { -> triggered++ }
println(o) // A
println("$o") // B
println("${o}") // C
After A, triggered is 0; after B, it's 1; after C, it's 2. The Closure is
being called and the result of it is being printed instead. Is this behavior
intended?
--
Sent from: http://groovy.329449.n5.nabble.com/Groovy-Dev-f372993.html
