On 22.12.2017 00:20, Paul King wrote:
I suspect this is intentional but was before my time. Try this also:int triggered = 0 def o1 = { -> triggered++ } def o2 = { println '*' + it; triggered++ } println(o1) // ConsoleScript11$_run_closure1@xxxxxxxx println(o2) // ConsoleScript11$_run_closure2@yyyyyyyy assert triggered == 0 println("xyzzy$o1") // xyzzy0 assert triggered == 1 println("XX${o2}YY${o2(42)}ZZ") // *42\n*XX\nXXYY1ZZ assert triggered == 3
ah yes... good old times with John Wilson... I think the idea was back then to leverage the Closures for templating engine purposes.. like for example GStringTemplateEngine the whole template in there is basically a Closure and writing is channeld by the writeTo method, that is also used for toString.
I really wonder how much this feature is used. If you look at the code you will see, that it does lead to very surprising behaviour, for example toString on Closure and writeTo in GString do not fit very well together and the GString base evaluation may lead to a double evaluation by working on the result of the Closure call. Plus of course the different behaviour for if the closure does or does not take a parameter where we one time work on the result and one time we ignore the result and instead let the Closure itself work things out.
Frankly, this is on my list of features to be removed. I have not yet fully investigated the impact of this - and I suspect there will be much more impact here than it looks like on first glance
bye Jochen
