[
https://issues.apache.org/jira/browse/GROOVY-11360?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17853432#comment-17853432
]
Eric Milles commented on GROOVY-11360:
--------------------------------------
[~lobodpav] I have been looking over the precedence of self/outer/super fields
versus inner class or closure/lambda protocols. Groovy performs special checks
for static fields within scope (see
{{AsmClassGenerator#checkStaticOuterField}}). There was a fix in 3.0.6 to
resolve within-closure regression (from 3.0.5) the same way:
https://github.com/apache/groovy/commit/419ce2f91754f101d8e65977da4dc7e8e6b6265f
The fix was not applied to Groovy 4 and I can't determine if that was
intentional. I don't want there to be one more subtle resolve difference
between Groovy 3 and 4 or between dynamic and static modes. So, I have fixed
the regression for Groovy 4 as well:
https://github.com/apache/groovy/commit/3c2266e053c4a9a9127be43921afb0c5135725f6
The dynamic property warning will continue to be produced for non-static
fields. But static fields should be resolved as they were previously in Groovy
4. Sorry for being so slow to come around on this.
----
Change that started this all off:
GROOVY-7701
Notices of the regression:
GROOVY-9501, GROOVY-9569, GROOVY-9650, GROOVY-9655, GROOVY-9665, GROOVY-9683,
GROOVY-9695, GROOVY-9699, GROOVY-9768, GROOVY-10604, GROOVY-10981,
GROOVY-11144, GROOVY-11360
Groovy 5 change for closures:
GROOVY-10985
Additional references:
GROOVY-3945, GROOVY-5737, GROOVY-6343, GROOVY-7490, GROOVY-8389, GROOVY-10329,
GROOVY-11056
> Issue a warning when accessing static fields that are "shadowed" by get()
> methods
> ---------------------------------------------------------------------------------
>
> Key: GROOVY-11360
> URL: https://issues.apache.org/jira/browse/GROOVY-11360
> Project: Groovy
> Issue Type: Improvement
> Components: Compiler
> Affects Versions: 4.0.21
> Reporter: Pavel Lobodinský
> Assignee: Eric Milles
> Priority: Minor
> Fix For: 5.0.0-alpha-9, 4.0.22
>
>
> h1. Introduction
> When having a static field in a class that is retrieved by lambda, a
> {{get()}} method is invoked instead. See the example code below, where
> {{DataClass#get}} is called instead of returning the value of the {{STR}}
> field.
> {code:groovy}
> class StaticPropertyIssueTest {
> static def STR = "test"
> static void main(String[] args) {
> def dataClass = new DataClass(value: "test")
> dataClass.with {
> assert value == STR
> }
> }
> }
> class DataClass {
> String value
> String get(String str) { "Hello" }
> } {code}
> In the https://issues.apache.org/jira/browse/GROOVY-11144 discussion, I
> learned that this is an expected behaviour.
> The main reason why I find this behaviour counter-intuitive is, that if the
> {{DataClass}} comes from a library, I have no clue the {{DataClass#get}}
> method exists. This problem always happens with AVRO-generated classes in
> particular, where every class extending the {{}}
> {code:java}
> org.apache.avro.specific.SpecificRecordBase{code}
> implements a
> {code:java}
> public Object get(String fieldName) { ... }{code}
> method.
> Actually, the {{get()}} method may even come from my own code, but I just
> don't realise it will be called because I simply only see the {{STR}} static
> field in my currently implemented class.
> h1. Improvement proposal
> Since this is the intended way Groovy is supposed to work, it would be
> amazing if the compiler could issue a warning that the static field's
> retrieval is shadowed by a getter method that will be called rather than
> returning the static field's value.
> In my eyes, this is something one simply does not expect. A compiler warning
> together with advice, that we must qualify the field retrieval by {{this}}
> keyword or by a class name, would help to understand the root cause of a
> misbehaving code.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
