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 <pa...@asert.com.au> Datum: 22.12.17 00:25 (GMT+01:00) An: dev@groovy.apache.org 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 <pa...@asert.com.au> 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 <nathanwhar...@gmail.com> 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