[jira] [Commented] (GROOVY-9936) Difference between Antlr2 and parrot parsers for variable declaration optimisation

["Paul King (Jira)" <ji...@apache.org>]

    [ https://issues.apache.org/jira/browse/GROOVY-9936?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17284181#comment-17284181 ] 

Paul King commented on GROOVY-9936:
-----------------------------------

The fix for this issue is only breaking if anyone has started relying on creating classes starting with an underscore or dollar and then created programs having variable declarations explicitly using such classes. Such programs would not have been valid in Groovy 2.x and the workaround for Groovy 1.x/2.x of using import aliasing is now also the recommended approach for Groovy 3+ for handling such cases.

> 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
>              Labels: breaking
>             Fix For: 3.0.8, 4.0.0-alpha-3
>
>          Time Spent: 1h 10m
>  Remaining Estimate: 0h
>
> 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)