groovy-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From MG <mg...@arscreat.com>
Subject Re: Groov 3.0 - nested code blocks - block/eval
Date Wed, 21 Mar 2018 00:53:37 GMT
Hi Daniel,

On 21.03.2018 01:33, Daniel Sun wrote:
>       Parrot is smart enough to distinguish closure and code block, so
> `block` is not necessary.

Under http://groovy-lang.org/releasenotes/groovy-3.0.html it says:

"Be aware though that in Groovy having a code block looking structure 
after any method call will be seen as an attempt to pass a closure as 
the last parameter in the method call. This happens even after a new 
line. So it’s safe to start an anonymous code block after any other 
block (e.g. an if-then-else statement or another anonymous code block). 
Anywhere else and you might need to terminate the previous statement 
with a semicolon. In which case, see the note above about refactoring 
your code! :-)"

If that is no longer true, it should be updated :-)

Apart from that, as I said, "block" would make the semantic explicit. I 
always found nested code blocks inelegant/error prone, so in C++ I used
#define block if(false) {} else

>   BTW, new keywords may break existing code ;)

Yes, every new reserverd word / keword must be evaluated whether it is 
worth introducing, also under this criteria.

>
>       As for `eval`, we can use `{ /* do something here */ }()` instead, e.g.
> `{ 'abc' }()`

Yes, that is what I used to use. Now I am wrapping it in a statically 
imported helper method, since the "()" at the end of the closure is 
syntactically inelegant:

static def eval(finalClosure cls) { cls() }

eval { ... }

But this creates a Closure instance, so it is inefficient. If Groovy had 
"inline closure" support, I would use that, but since it looks like this 
is still a long way off (if it ever comes - it was shot down a few years 
back when someone else created a ticket for it), I suggest this special 
version of it.

Cheers,
mg





Mime
View raw message