groovy-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Dierk König <dierk.koe...@canoo.com>
Subject Re: Groov 3.0 - nested code blocks - block/eval
Date Wed, 21 Mar 2018 06:15:09 GMT
I’m against breaking changes and changing core concepts for so little gain. 

Groovy has (x) to make x an expression. We could make that lexically scoped. 

Dierk

sent from:mobile 

> Am 21.03.2018 um 01:53 schrieb MG <mgbiz@arscreat.com>:
> 
> 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