paulk-asert commented on PR #2580:
URL: https://github.com/apache/groovy/pull/2580#issuecomment-4665157169
The above table was wrong. Here is the revised one:
For reference, here's the full `m.k` vs `m['k']` vs `m.get('k')` matrix on
6.0 after this change, across dynamic and `@CompileStatic` access. Every cell
is now pinned by the live tables in `_working-with-collections.adoc` /
`WorkingWithCollectionsTest.groovy`.
**Plain map** — `[foo:'bar']` / `[class:'C']` / `[:]`
| key | `m.k` | `m.k`
(`@CompileStatic`) | `m['k']` | `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` | `m.k` (`@CompileStatic`) |
`m['k']` | `m.get('k')` |
| ------------------------------- | ----- | ------------------------ |
-------- | ------------ |
| `'foo'` (property=1, entry=11) | `1` | `1` | `11`
| `11` |
| `'bar'` (property=2, no entry) | `2` | `2` |
`null` | `null` |
| `'baz'` (no property, entry=33) | `33` | `33` | `33`
| `33` |
Takeaways:
1. **`m['k']` ≡ `m.get('k')` in every row and in both modes** — that's the
invariant this PR restores (subscript was previously diverging under static
resolution).
2. **`m.k` and `m['k']` agree on a plain map** but legitimately differ on a
subclass: `m.k` reads the declared property when one exists (falling back to
the entry), while `m['k']`/`get` always read the entry. Dynamic and
`@CompileStatic` columns now match throughout, so the only axis that matters is
property-vs-entry, not dynamic-vs-static.
3. Practical guidance: use `['k']`/`get` whenever you mean "the entry";
reserve `m.k` for property semantics.
---
--
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]
