Hi Daniel,

good to hear you seem to be well :-)

Maybe I am missing something, but right now I don't see where writing a standalone closure in the code would makes sense, since it is not assigned to anything, and its creation has no side effects (?)

The only application I can see is calling it immediately inline, which I have sometimes done in the past to do e.g. some if-then-else-cascade based calculations depending on parameters/variables from surrounding scope  and assign the result to a final variable (without having to introduce a method). I have however switched to using a static eval method for that case, since it is much cleaner:

final x = { ...  }.call()

final x = eval { ... }

with statically imported (trivial) eval method

static <T> T eval(final Closure<T> cls) { cls() }

Cheers,
mg


On 28/03/2020 04:06, Daniel.Sun wrote:
Hi all,

        Current groovy grammar of method call contains the following
ambiguities, which are odd for users. For example,

1) method call with closure argument. That means the closure on the next
line could be treated as argument of method `meth`
```
meth
{ p ->
}
```

2) binary expression and closure expression. That means the closure is not
an argument.
```
a | meth
{ p ->
}
```

        I propose to unify the grammar of closure arguments: when closure
follows method name directly, it is an argument, otherwise it is just
standalone closure. For example,

3) method call with closure argument
```
meth { p ->
}
```

4) variable and closure
```
meth
{ p ->
}
```

        Luckily, groovy-parser project containing source code of some famous
groovy projects, none of which are broken because of the proposed change[1].

        Here is a JIRA ticket[2] to track the proposed change, and here is
the PR[3] to implement the change.

        Any thoughts?

Cheers,
Daniel Sun
[1] https://github.com/danielsun1106/groovy-parser/commits/GROOVY-9484
[2] https://issues.apache.org/jira/browse/GROOVY-9484
[3] https://github.com/apache/groovy/pull/1211




-----
Apache Groovy committer & PMC member
Blog: http://blog.sunlan.me
Twitter: @daniel_sun

--
Sent from: http://groovy.329449.n5.nabble.com/Groovy-Dev-f372993.html

Reply via email to