I know where you are coming from. On the other hand, this is maybe the
sole reason why anyone would need a language after Groovy: Historic
features being frozen because of the fear that a change might break some
existing code...
However I do not think that this behavior, as unexpected as it mi
We've settled on that behavior a long time ago, so it's quite blurry in my
mind, to be honest.
I'd be a bit afraid of making changes to how things are working now, as it
might have some unintended consequences.
I mean, making some changes there could break people's code in unexpected
places, and I
Are there any more thoughts on whether or not this behavior should be
changed? I say it is confusing and unnecessary. I think it's important to
keep the behavior advertised for Closures intact, eg: "hello {-> 0}" should
still render 0, but a reference to a Closure should not automatically call
toS
On 22.12.2017 16:55, Daniel.Sun wrote:
Hi Jochen,
As far as I remember, John Wilson is one of main contributors of
Groovy, he is active in about 2007 and rejected some proposals of mine ;-)
he did a lot of work for Groovy 1.0 for example and way before too (with
a gap of quite some ti
Hi Jochen,
As far as I remember, John Wilson is one of main contributors of
Groovy, he is active in about 2007 and rejected some proposals of mine ;-)
Cheers,
Daniel.Sun
--
Sent from: http://groovy.329449.n5.nabble.com/Groovy-Dev-f372993.html
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@
println(o2) // ConsoleScript11$_run_closure2@
Yeah, I don't understand this behavior either. Seems better to write "${o()}"
if you want call it. Anyone against changing that?
MG, yes that operator has been proposed for Parrot, but I'm not sure what
happened to it. Maybe start another thread for it.
--
Sent from: http://groovy.329449.n5.nab
definitions, and elegantly assign the default value in the last
method called...
Ursprüngliche Nachricht Von: Paul King
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
Or change the last two lines a little more:
println("XX${o2}YY${o2(42)}ZZ$o2") // *42\n*XX\n*XXYY1ZZ\nXXYY1ZZ
assert 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 wrote:
> I suspect this is intentional but was before my t
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@
println(o2) // ConsoleScript11$_run_closure2@
assert triggered == 0
println(
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
int
11 matches
Mail list logo
