I see, then I agree that it's not a big issue.
I was confused because I saw that Gradle supports that syntax. Not
understanding how they can, then?
Cheers, p
On Wed, Apr 1, 2020 at 3:30 PM Paul King wrote:
> Groovy 2.5 and earlier don't support this form. But yes, if any Groovy 3
> DSLs
Groovy 2.5 and earlier don't support this form. But yes, if any Groovy 3
DSLs were created in the last few weeks (or longer if we count betas/RCs)
and they used this form, then they would break.
Cheers, Paul.
On Wed, Apr 1, 2020 at 10:56 PM Paolo Di Tommaso
wrote:
> Arriving late to this
Arriving late to this thread, therefore not sure it has already discussed,
but have you taken in consideration that changing the method call argument
interpretation for the case 1, eg.
meth
{ p ->
}
it will break all DSL in which the user scripts use this form? Just
thinking Gradle for example.
I see, that's a though one, then, if one wants people to be able to put
heir braces where they want*...
I have turned this back and forth in my mind, and I think the current
Groovy 2.5.x behavior is actually a good/practical compromise, even
though it might appear confusing at first in some
On 29.03.20 14:17, Paul King wrote:
Groovy's original rule was that a newline terminates a statement when it
could sensibly finish (successfully complete an expression) at that
point. So if you've opened a curly brace or bracket, for instance, the
newline would not auto-terminate an
Groovy's original rule was that a newline terminates a statement when it
could sensibly finish (successfully complete an expression) at that point.
So if you've opened a curly brace or bracket, for instance, the newline
would not auto-terminate an expression/statement.
The rule was later expanded
Nice catch ;-)
Cheers,
Daniel.Sun
-
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
Hi Jochen,
> How about unifying the other way around and make 1 and 2 both a method
> call with a closure for meth?
Groovy 3 has already unified them by accident... but some spock code is
broken, so we are trying to find a way to please everyone ;-)
```
modification
Hi MG,
Understood. Some spock code care the differences, e.g. the following
code
```
modification| expected
{ Instant i, ZoneId z -> i.plusSeconds(1) } | defaultInstant.plusSeconds(1)
```
is expected to parsed as 2 binary expressions:
```
modification
Actually, we have already force some code style... But the code style is not
unified:
2.5.8 parses the following code as a variable and a method call with closure
argument
```
a | meth { p ->
}
```
Let's add a newline. 2.5.8 parses the following code as binary expression
and a closure
```
a |
AFAIK, Groovy learned quite a few design ideas from many great language,
e.g. Ruby. The optional parentheses feature was inspired by Ruby. The
feature makes Groovy more friendly as DSL to users, but ambiguities
introduced... Ruby has similar troubles(See the following link)
> On Mar 29, 2020, at 0:19, Milles, Eric (TR Tech, Content & Ops)
> wrote:
>
> Is there any language that differentiates between one space and multiple
> whitespaces as a separator? My experience with C, C++, Java, Groovy, etc. is
> that any number of whitespaces are the same in terms of
On 28.03.20 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`
```
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
dev@groovy.apache.org
Subject: RE: About eliminating ambiguities of method call with closure argument
Is there any language that differentiates between one space and multiple
whitespaces as a separator? My experience with C, C++, Java, Groovy, etc. is
that any number of whitespaces are the same in t
Is there any language that differentiates between one space and multiple
whitespaces as a separator? My experience with C, C++, Java, Groovy, etc. is
that any number of whitespaces are the same in terms of separation between
tokens.
In terms of parsing, you can't tell that an identifier is a
16 matches
Mail list logo
