[
https://issues.apache.org/jira/browse/GROOVY-8131?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15942331#comment-15942331
]
Richard Elkins edited comment on GROOVY-8131 at 3/26/17 4:26 PM:
-----------------------------------------------------------------
To me, the following two executable statements are semantically identical:
static final SimpleDateFormat s2 =
new SimpleDateFormat( "yyyy-MM-dd_hh:mm:ss" );
static final SimpleDateFormat s3
= new SimpleDateFormat( "yyyy-MM-dd_hh:mm:ss" );
When I was a compiler constructor, newline characters (line continuation) was
treated as whitespace (0x20). It doesn't matter whether the scanner employs a
terminator or the scanner simply recognizes the end of a valid statement.
When one escapes the newline character in the 1st line of the s3 declaration,
then `groovyc` compiles the 2-line statement successfully.
static final SimpleDateFormat s3m \
= new SimpleDateFormat( "yyyy-MM-dd_hh:mm:ss" );
If the newline is a statement separator (like semicolon), then why weren't both
the s2 and s3m declarations flagged?
1. They are declared as final yet they have no declared initialization
before statement separation.
2. The 2nd line should be a syntax error as they are assignments with
nothing to assign to.
Answer guess: Full statements are recognized syntactically (terminate
implicitly), regardless of the number of lines the statement occupies.
I still think that the original report is against an undesirable feature of the
`groovyc` scanner. If both lines are recognized as part of a single executable
statement, then it should not matter where the '=' character falls on (line 1
or line 2). Semantically, the s2 and s3 declarations are identical.
Am I missing some subtle philosophical point of Groovy?
I can catch these types of differences in my Java source code fairly easily,
hence, the report was classified as "minor".
was (Author: texadactyl):
To me, the following two executable statements are semantically identical:
static final SimpleDateFormat s2 =
new SimpleDateFormat( "yyyy-MM-dd_hh:mm:ss" );
static final SimpleDateFormat s3
= new SimpleDateFormat( "yyyy-MM-dd_hh:mm:ss" );
When I was a compiler constructor, newline characters (line continuation) was
treated as whitespace (0x20). It doesn't matter whether the scanner employs a
terminator or the scanner simply recognizes the end of a valid statement.
When one escapes the newline character in the 1st line of the s3 declaration,
then `groovyc` compiles the 2-line statement successfully.
static final SimpleDateFormat s3m \
= new SimpleDateFormat( "yyyy-MM-dd_hh:mm:ss" );
If the newline is a statement separator (like semicolon), then why weren't both
the s2 and s3m declarations flagged?
1. They are declared as final yet they have no declared initialization
before statement separation.
2. The 2nd line should be a syntax error as they are assignments with
nothing to assign to.
Answer guess: Full statements are recognized syntactically (terminate
implicitly).
I still think that the original report is against an undesirable feature of the
`groovyc` scanner. If both lines are recognized as part of a single executable
statement, then it should not matter where the '=' character falls on (line 1
or line 2). Semantically, the s2 and s3 declarations are identical.
Am I missing some subtle philosophical point of Groovy?
I can catch these types of differences in my Java source code fairly easily,
hence, the report was classified as "minor".
> Statement continued onto next line is flagged when first character is "="
> -------------------------------------------------------------------------
>
> Key: GROOVY-8131
> URL: https://issues.apache.org/jira/browse/GROOVY-8131
> Project: Groovy
> Issue Type: Bug
> Components: Compiler
> Affects Versions: 2.4.5
> Environment: Ubuntu Linux
> `uname -a`:
> Linux biostar 4.4.0-69-generic #90-Ubuntu SMP Thu Mar 16 16:52:31 UTC 2017
> x86_64 x86_64 x86_64 GNU/Linux
> Reporter: Richard Elkins
> Priority: Minor
> Attachments: grbug.java
>
>
> Source code attached (grbug.java).
> `javac` v8 compiles variable declarations s1, s2, and s3 successfully.
> `groovyc` flags s3:
> "unexpected token: = @ line 9, column 3."
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
