I think it is worth reviewing some of these edge cases but we want to keep
the overall conceptual
model describing the parser behavior (i.e. parser rules) as simple as
possible.
Here is my understanding of the rules for the classic parser. Java supports
a fluent api style such as:
String lowerCity = person
.getAddress()
.getCity()
.getName()
.toLowerCase();
Java knows when to stop because of the trailing semicolon. Groovy doesn't
require the trailing
semicolon so has the following additional rules. If the tokens at the end
of a line don't make up
a complete expression, looking onto the next line is done. This accounts
for various opening and
closing delimiters but also when using '.'. This allows expressions like:
assert person.
address.
city.
name.
toLowerCase() == 'berlin'
and:
def foobar1 = 'foo' +
'bar1'
assert foobar1.size() == 7
def baz =
'baz'
println baz
As a follow-on rule, even if a line ends with valid tokens but the
subsequent line doesn't start with
valid tokens (in particular starts with a '.') we try to join. This allows
for:
assert person
.address
.city
.name
.size() == 6
But doesn't allow for:
def foobar2 = 'foo'
+ 'bar2'
which compiles but gives a runtime error:
MissingMethodException: No signature of method: java.lang.String.positive()
Since + here is the unary plus operator which while seldom used in that
fashion is a valid operator.
Strangely, the foobar2 example parses and runs successfully on Groovy 3
setting
foobar2 to 'foo'. I'll have to check if that is a bug or "feature".
Groovy 2.5 similarly doesn't allow:
println 'foo'.with
{ s -> s.size() }
It compiles but fails to find the 'with' property on the 'foo' String. So
these are two
fully valid expressions one after the other.
Groovy 3 does allow this last case. That's a breaking change. I'll need to
double
check if that is something we have discussed previously and add it to the
3.0 breaking
changes if so.
Neither Groovy 2.5 nor 3 supports an anonymous inner class creation with the
curly brace on the subsequent line:
def bar = new Object()
{ String toString() { 'bar' } } // Method def not expected here
println bar.toString()
Anyway, given the above rules, my first inclination would be to retain
at least the GROOVY-8642 syntax and possibly GROOVY-8650.
I agree the use of those rules within an import is ugly but I see it
as consistent application of those rules.
But having said that, if we can describe an alternative set of rules
that are just as simple, we can have a slightly refined way of describing
the parser behavior for Groovy 3.0. I'd prefer not though to have
a very piece-meal set of rules where every construct needs to be
described separately.
Cheers, Paul.
On Tue, Jul 3, 2018 at 12:44 PM Daniel.Sun <sun...@apache.org> wrote:
> Hi all,
>
> The following code is supported in the older parser, but I propose to
> stop supporting the ugly code style in the new Parrot parser. Any thoughts?
>
> 1) import statement ( https://issues.apache.org/jira/browse/GROOVY-8642 )
> ```
> import java.
> lang.
> Object
> ```
>
> 2) prefix operator ( https://issues.apache.org/jira/browse/GROOVY-8650 )
> ```
> def c = --
> 1
> ```
>
> Cheers,
> Daniel.Sun
>
>
>
>
> -----
> Daniel Sun
> Apache Groovy committer
> Blog: http://blog.sunlan.me
> Twitter: @daniel_sun
>
> --
> Sent from: http://groovy.329449.n5.nabble.com/Groovy-Users-f329450.html
>
