paulk-asert commented on PR #3067:
URL: https://github.com/apache/groovy/pull/3067#issuecomment-6649992450
Thanks Daniel, this is a careful piece of work, but I am also worried about
Eric's concern. I probed the PR, merged with current master, against 4.0.32,
5.1.3, 6.0.0 and master in dynamic, TC and CS code. The reported shape is
fixed, but the rewrite has wider effects:
- Non-Map anonymous classes change. If the anonymous class's superclass has
a property or getter with the same name as an enclosing field (class Base {
String VALUE = 'base' }; new Base() {{ got = VALUE }}), 5.x/6.x/master read
base, per GROOVY-10985, and the PR reads the outer field. The existing
super-field test uses a name the outer class doesn't have, so it doesn't catch
this.
- Closure delegates are bypassed. In an initializer, new D().with { put('k',
VALUE) }, where D has VALUE, now reads the outer field rather than the delegate.
- One name, two targets. Because assignments are left alone, VALUE =
'entry'; put('k', VALUE) writes the map entry but then reads the outer field.
COUNT++ updates the outer field while COUNT = x writes the map entry.
- Partial restoration. Methods of the same anonymous class, named inner
classes and map.with { } keep the 5.x rule, so we'd have three precedence rules
depending on where the name appears.
Given the simple workaround (qualify with Outer.VALUE, or use a map literal)
and that the docs already cover the gotcha, I'd prefer to keep the GROOVY-10985
rule uniform. I suggest we close this and resolve the JIRA as working as
designed.
I did do a spike to address just the silent null, to give a compile-time
warning when a bare name in a Map/List subclass matches an enclosing field, but
even that was very complicated and didn't handle some of the cases.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
