You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@groovy.apache.org by MG <mg...@arscreat.com> on 2018/03/21 00:15:21 UTC
Groov 3.0 - nested code blocks - block/eval
With regards to the Groovy 3.0 Release Notes
(http://groovy-lang.org/releasenotes/groovy-3.0.html) "Nested code
blocks" section:
What about in addition supporting two reserved keywords, "block" and
"eval", as follows:
void foo() {
block {
// Makes nested code block explicit (without it, the block could
e.g. have a missing if or else construct before it)
// Avoids the need to use semicolon before nested code block to
distinguish code block from a closure
// Otherwise no difference to Java nested code block
}
// equivalent to:
if(true) { ... }
final x = eval {
// Nested code block whose final evaluated statement is its return
value
}
// semi-equivalent to:
final x = true ? (...;...;...) : null
}
The application for these constructs for me lie in cases where one needs
to create a scope with a local variables, but where one would need to
pass a large number of parameters to a helper method that coud be
introduced, or one would really have to try hard to come up with a
meaningful method name (implying that the functionality is too
small/specialized to be moved into a seperate method).
Thoughts ?
mg
Unsubscribe
Posted by OmniTrade <om...@gmail.com>.
On Tue, Mar 20, 2018, 5:15 PM MG, <mg...@arscreat.com> wrote:
> With regards to the Groovy 3.0 Release Notes
> (http://groovy-lang.org/releasenotes/groovy-3.0.html) "Nested code
> blocks" section:
> What about in addition supporting two reserved keywords, "block" and
> "eval", as follows:
>
> void foo() {
> block {
> // Makes nested code block explicit (without it, the block could
> e.g. have a missing if or else construct before it)
> // Avoids the need to use semicolon before nested code block to
> distinguish code block from a closure
> // Otherwise no difference to Java nested code block
> }
>
> // equivalent to:
> if(true) { ... }
>
>
> final x = eval {
> // Nested code block whose final evaluated statement is its return
> value
> }
>
> // semi-equivalent to:
> final x = true ? (...;...;...) : null
> }
>
>
> The application for these constructs for me lie in cases where one needs
> to create a scope with a local variables, but where one would need to
> pass a large number of parameters to a helper method that coud be
> introduced, or one would really have to try hard to come up with a
> meaningful method name (implying that the functionality is too
> small/specialized to be moved into a seperate method).
>
> Thoughts ?
> mg
>
>
>
>
Re: Groov 3.0 - nested code blocks - block/eval
Posted by Dierk König <di...@canoo.com>.
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 <mg...@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
>
>
>
>
Re: Groov 3.0 - nested code blocks - block/eval
Posted by MG <mg...@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
Re: Groov 3.0 - nested code blocks - block/eval
Posted by Daniel Sun <re...@hotmail.com>.
Hi mg,
Parrot is smart enough to distinguish closure and code block, so
`block` is not necessary. BTW, new keywords may break existing code ;)
As for `eval`, we can use `{ /* do something here */ }()` instead, e.g.
`{ 'abc' }()`
P.S. I am open to any proposal for grammar ;-)
Cheers,
Daniel.Sun
--
Sent from: http://groovy.329449.n5.nabble.com/Groovy-Users-f329450.html