You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@groovy.apache.org by "Daniel.Sun" <su...@apache.org> on 2018/07/03 02:44:41 UTC

About the groovy code style

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

Re: About the groovy code style

Posted by "Daniel.Sun" <su...@apache.org>.
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

Re: About the groovy code style

Posted by Paul King <pa...@asert.com.au>.
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 <su...@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
>

Re: About the groovy code style

Posted by Paul King <pa...@asert.com.au>.
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 <su...@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
>

Re: About the groovy code style

Posted by "Daniel.Sun" <su...@apache.org>.
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

Re: About the groovy code style

Posted by Daniil Ovchinnikov <da...@jetbrains.com>.
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 <su...@apache.org> 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

Re: About the groovy code style

Posted by "Daniel.Sun" <su...@apache.org>.
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

Re: About the groovy code style

Posted by Daniil Ovchinnikov <da...@jetbrains.com>.
You mean me?

—

Daniil Ovchinnikov
JetBrains


> On 4 Jul 2018, at 05:39, Daniel.Sun <su...@apache.org> 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

Re: About the groovy code style

Posted by "Daniel.Sun" <su...@apache.org>.
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

Re: About the groovy code style

Posted by MG <mg...@arscreat.com>.
Two questions:

 1. Jochen says "Danil  is doing special things with DSL", but "Daniil
    Ovchinnikov" replied regarding IntelliJ Groovy parsing. So is Danil
    == Daniil ?
 2. I neither like nor use these syntax varieties - but wouldn't
    changing any of that behavior potentially break Groovy DSLs from
    here to Baghdad (not only "Danil"'s) ?-)

Cheers,
mg


On 04.07.2018 20:40, Paul King wrote:
>
> Comment inline.
>
> On Tue, Jul 3, 2018 at 10:31 PM Jochen Theodorou <blackdrag@gmx.org 
> <ma...@gmx.org>> 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
>

Re: About the groovy code style

Posted by Jochen Theodorou <bl...@gmx.org>.
On 04.07.2018 20:40, Paul King wrote:
[...]
> 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?

I think it is important to have simple and consistent set of rules and 
as such I reconsidered my comment and say that for the sake of 
completeness to allow something like:

fooo.
   bar().
   otherFoo()

(or take an example with +), which follows this rule should be 
supported, even if that means supporting

import fooo.
   bar.
   x

or the example with --. I think it should not necessarily be our task to 
prevent people from writing ugly looking code. For that I would like to 
have a secondary tool.

Thank you for reminding.

bye Jochen

Re: About the groovy code style

Posted by Paul King <pa...@asert.com.au>.
Comment inline.

On Tue, Jul 3, 2018 at 10:31 PM Jochen Theodorou <bl...@gmx.org> 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
>

Re: About the groovy code style

Posted by Jochen Theodorou <bl...@gmx.org>.

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