[
https://issues.apache.org/jira/browse/GROOVY-12024?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=18087760#comment-18087760
]
ASF GitHub Bot commented on GROOVY-12024:
-----------------------------------------
paulk-asert commented on PR #2580:
URL: https://github.com/apache/groovy/pull/2580#issuecomment-4664134906
> The key reframing: under the **dynamic** runtime, `m['k']` already means
`m.get('k')` for every key — `[:].class`, `[:].properties`, `[:].metaClass` all
return `null` (the absent entry), not the bean. The surprising behavior was
confined to **static** resolution, where subscript was binding to the
property-access overload. So this PR isn't trading one consistency for another
so much as **realigning STC subscript with the long-standing dynamic
semantics** (and with `get`/`put`).
>
> Verified values (dynamic against the runtime; static column = intended 6.0
/ the STC test assertions in this PR):
>
> **Plain map** — `[foo:'bar']` / `[class:'C']` / `[:]`
>
> | key | `m.k` dynamic | `m.k` `@CompileStatic` | `m['k']` (6.0) |
`m.get('k')` |
> |---|---|---|---|---|
> | ordinary (`'foo'`) | `'bar'` | `'bar'` | `'bar'` | `'bar'` |
> | meta-name present (`'class'`→`'C'`) | `'C'` (entry, not the Class) |
`'C'` | `'C'` | `'C'` |
> | meta-name absent (`'class'`) | `null` | `null` | `null` | `null` |
>
> **Map subclass** — `class C extends HashMap { def foo = 1; def bar = 2 }`,
then `put('foo',11)`, `put('baz',33)`
>
> | key | `m.k` dynamic | `m.k` `@CompileStatic` | `m['k']` (6.0) |
`m.get('k')` |
> |---|---|---|---|---|
> | declared prop **and** entry (`'foo'`: prop=1, entry=11) | **`11`**
(entry wins) | **`1`** (property wins) | `11` | `11` |
> | declared prop, **no** entry (`'bar'`: prop=2) | **`null`** (property
ignored) | **`2`** (property) | `null` | `null` |
> | entry, **no** declared prop (`'baz'`: entry=33) | `33` | `33` | `33` |
`33` |
>
> Two takeaways:
>
> 1. **After this PR, `m['k']` ≡ `m.get('k')` in every row and both modes**
— one clean column, no asterisks. That's the win worth stating explicitly as
the invariant.
> 2. The genuinely treacherous cell is **`m.k` on a Map subclass**, which
disagrees dynamic-vs-static (entry wins dynamically, declared property wins
under STC). This PR doesn't touch dot access, so that divergence remains —
subscript just sidesteps it now. Might be worth a follow-up issue, or at least
a doc note steering entry access to `[]`/`get`.
>
> Suggestion for locking it in: pin the invariant as a paired test that runs
the same asserts under dynamic **and** `@CompileStatic`, so the static/dynamic
gap that caused this can't silently reopen via overload-resolution drift. Happy
to put that together if helpful.
> Subscript operator for Map has unexpected behavior when key is 'properties'
> ---------------------------------------------------------------------------
>
> Key: GROOVY-12024
> URL: https://issues.apache.org/jira/browse/GROOVY-12024
> Project: Groovy
> Issue Type: Bug
> Reporter: David Costanzo
> Assignee: Eric Milles
> Priority: Minor
>
> The subscript operator has strange behavior for Map when the key is
> 'properties'. Instead of accessing the value associated with that key, it
> accesses a read-only Map object.
> This behavior changed between Groovy 3 and Groovy 5. My expectation is that
> the subscript operator can access values for a key named 'properties', as it
> did in Groovy 3.
> *Steps to Reproduce:*
> In groovysh 5, the subscript operator references the system-provided,
> read-only map.
>
> {code:java}
> groovy> map = ['properties': 1]
> groovy> map['properties']
> [:]
> groovy> map['properties'] = 2
> ReadOnlyPropertyException: Cannot set read-only property: properties for
> class: java.util.LinkedHashMap{code}
>
> In groovysh 3, the subscript operator references keys of the user-created map.
>
> {code:java}
> groovy:000> map = ['properties': 1]
> ===> [properties:1]
> groovy:000> map['properties']
> ===> 1
> groovy:000> map['properties'] = 2
> ===> 2{code}
>
> I don't know if this is intentional, but I couldn't find a reference to in
> the documentation. On
> [https://docs.groovy-lang.org/latest/html/documentation/#subscript-operator]
> it says that the subscript operators is a shorthand for getAt() and setAt().
> On
> [https://docs.groovy-lang.org/latest/html/groovy-jdk/java/util/Map.html#getAt(java.lang.Object)]
> it does not mention that "properties" can't be used as a key.
> In my view, this is either a code bug (an internal implementation detail is
> being exposed beyond it's intended scope) or a doc bug (the subscript
> operator or Map.getAt() should mention the reserved system key named
> "properties").
> *Impact:*
> This creates the potential for hidden bugs. For example, I have a script
> that manages some metadata for internal libraries using a map keyed by the
> library name. The script appears to work correctly, but then I add a
> library named "properties" and the script fails to work. (This is not
> theoretical, this is what actually happened to me).
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
