Mailing-List: contact dev-help@groovy.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@groovy.apache.org
Subject: Re: G-String embedded Closure calling bug?
To: dev@groovy.apache.org
References: <1513894844444-0.post@n5.nabble.com>
 <CAMbkE7R_CbDt7u6iGGtJEpstDbDSon1j3ifMzWMHqTeb3ZxoxA@mail.gmail.com>
From: Jochen Theodorou <blackdrag@gmx.org>
Message-ID: <b2dd522c-52f5-ee75-fdd6-c24e28fab468@gmx.org>
Date: Fri, 22 Dec 2017 03:39:51 +0100
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101
 Thunderbird/52.1.1
MIME-Version: 1.0
In-Reply-To: <CAMbkE7R_CbDt7u6iGGtJEpstDbDSon1j3ifMzWMHqTeb3ZxoxA@mail.gmail.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: 7bit
archived-at: Fri, 22 Dec 2017 02:40:04 -0000

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