About the groovy code style

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
12 messages Options
12
Reply | Threaded
Open this post in threaded view
|

About the groovy code style

Daniel.Sun
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
Daniel Sun
Apache Groovy committer

Blog: http://blog.sunlan.me
Twitter: @daniel_sun
Reply | Threaded
Open this post in threaded view
|

Re: About the groovy code style

paulk_asert
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 <[hidden email]> 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
Reply | Threaded
Open this post in threaded view
|

Re: About the groovy code style

Jochen Theodorou
In reply to this post by Daniel.Sun


Am 03.07.2018 um 04:44 schrieb Daniel.Sun:

> 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

I do not need these.. but since I know Danil is doing special things
with DSL, maybe we should first ask him if he needs that and why

bye Jochen
Reply | Threaded
Open this post in threaded view
|

Re: About the groovy code style

Daniel.Sun
ping Danil  :-)



-----
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
Daniel Sun
Apache Groovy committer

Blog: http://blog.sunlan.me
Twitter: @daniel_sun
Reply | Threaded
Open this post in threaded view
|

Re: About the groovy code style

Daniel.Sun
In reply to this post by paulk_asert
Hi Paul,

> 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".

It is a bug of Parrot and is fixed in 3.0.0-alpha-4. See
https://github.com/apache/groovy/commit/2c1f7e3c47b3c1d12c05a1540307c43f1267b10f

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
Daniel Sun
Apache Groovy committer

Blog: http://blog.sunlan.me
Twitter: @daniel_sun
Reply | Threaded
Open this post in threaded view
|

Re: About the groovy code style

daniil.ovchinnikov
In reply to this post by Daniel.Sun
You mean me?



Daniil Ovchinnikov
JetBrains


On 4 Jul 2018, at 05:39, Daniel.Sun <[hidden email]> wrote:

ping Danil  :-)



-----
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

Reply | Threaded
Open this post in threaded view
|

Re: About the groovy code style

Daniel.Sun
Yep. Daniil.



-----
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
Daniel Sun
Apache Groovy committer

Blog: http://blog.sunlan.me
Twitter: @daniel_sun
Reply | Threaded
Open this post in threaded view
|

Re: About the groovy code style

daniil.ovchinnikov
Each introduced change make tooling more complicated. While some constructs become invalid in newer compiler, IntelliJ still has to support all Groovy versions.

So in IntelliJ we will continue to parse as in old version, but I’ll have to add error highlighting and tweak formatter for 3.0, unless you decide to support such corner cases in 3.0. 

Daniil Ovchinnikov
JetBrains


On 4 Jul 2018, at 14:27, Daniel.Sun <[hidden email]> wrote:

Yep. Daniil.



-----
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

Reply | Threaded
Open this post in threaded view
|

Re: About the groovy code style

Daniel.Sun
Hi Daniil,

OK. I see.
I am not going to support the ugly code style... but I want to know what
others think about :-)

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
Daniel Sun
Apache Groovy committer

Blog: http://blog.sunlan.me
Twitter: @daniel_sun
Reply | Threaded
Open this post in threaded view
|

Re: About the groovy code style

paulk_asert
In reply to this post by Jochen Theodorou

Comment inline.

On Tue, Jul 3, 2018 at 10:31 PM Jochen Theodorou <[hidden email]> wrote:


Am 03.07.2018 um 04:44 schrieb Daniel.Sun:
> 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

I do not need these.. but since I know Danil is doing special things
with DSL, maybe we should first ask him if he needs that and why

Jochen, even though you say you "do not need these", the real question is what set of rules are you replacing the existing conceptual rule with?

Existing rule: if the set of tokens parsed when an end of line is reached doesn't make a complete expression/statement, continue reading tokens as if the EOL wasn't there.

There are exceptions, e.g. we currently don't allow single quote and single double quoted strings to span multiple lines but the list is short.

What are your new rules and new list of exceptions?

We shouldn't be tied down by our existing set of rules but we want to keep them simple for our users so they all don't need to be grammar experts to use the language.

Cheers, Paul.
 
bye Jochen
12