[
https://issues.apache.org/jira/browse/GROOVY-9936?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Paul King updated GROOVY-9936:
------------------------------
Description:
As an optimisation for parsing, both parsers treat statements like:
{code}
int var1
Foo var2
Bar var3
{code}
as variable declarations due to the starting capital letter of the first term
(for non-primitives).
And the following are treated by both parsers as command expressions:
{code}
foo x
bar y
{code}
due to the lowercase starting letter of the first term. If a class starts with
a lowercase letter (valid though not conventional) the workaround where a
variable declaration is desired is to use something like:
{code}
import myClass as MyClass
MyClass foo
{code}
A difference in behavior can be noted for cases starting with underscore or
dollar (the only other characters available for the first letter of a class
name):
{code}
_foo bar
$bar baz
{code}
These were command expressions for the old parser and are being coerced to
variable declarations in the Parrot parser.
We need to decide whether to alter these last two cases for backwards
compatibility or whether we see this as a breaking change which better aligns
with the Java specification.
I propose we opt for backwards compatibility since the above mentioned
workaround would apply equally for classes with these starting characters,
whereas renaming a method starting with these characters is more complicated.
was:
As an optimisation for parsing, both parsers treat statements like:
{code}
int var1
Foo var2
Bar var3
{code}
as variable declarations due to the starting capital letter of the first term
(for non-primitives).
And the following are treated by both parsers as command expressions:
{code}
foo x
bar y
{code}
due to the lowercase starting letter of the first term. If a class starts with
a lowercase letter (valid though not conventional) the workaround where a
variable declaration is desired is to use something like:
{code}
import myClass as MyClass
MyClass foo
{code}
A difference in behavior can be noted for cases starting with underscore or
dollar (the only other characters available for the first letter of a class
name):
{code}
_foo bar
$bar baz
{code}
These were command expressions for the old parser and are being coerced to
variable declarations in the Parrot parser.
We need to decide whether to alter these last two cases for backwards
compatibility or whether we see this as a breaking change which better aligns
with the Java specification.
I propose we opt for backwards compatibility since the above mentioned
workaround would apply equally for classes with these starting characters but
renaming a method starting with these characters is more complicated.
> Difference between Antlr2 and parrot parsers for variable declaration
> optimisation
> ----------------------------------------------------------------------------------
>
> Key: GROOVY-9936
> URL: https://issues.apache.org/jira/browse/GROOVY-9936
> Project: Groovy
> Issue Type: Bug
> Components: parser-antlr4
> Reporter: Paul King
> Assignee: Paul King
> Priority: Major
>
> As an optimisation for parsing, both parsers treat statements like:
> {code}
> int var1
> Foo var2
> Bar var3
> {code}
> as variable declarations due to the starting capital letter of the first term
> (for non-primitives).
> And the following are treated by both parsers as command expressions:
> {code}
> foo x
> bar y
> {code}
> due to the lowercase starting letter of the first term. If a class starts
> with a lowercase letter (valid though not conventional) the workaround where
> a variable declaration is desired is to use something like:
> {code}
> import myClass as MyClass
> MyClass foo
> {code}
> A difference in behavior can be noted for cases starting with underscore or
> dollar (the only other characters available for the first letter of a class
> name):
> {code}
> _foo bar
> $bar baz
> {code}
> These were command expressions for the old parser and are being coerced to
> variable declarations in the Parrot parser.
> We need to decide whether to alter these last two cases for backwards
> compatibility or whether we see this as a breaking change which better aligns
> with the Java specification.
> I propose we opt for backwards compatibility since the above mentioned
> workaround would apply equally for classes with these starting characters,
> whereas renaming a method starting with these characters is more complicated.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
