daniellansun commented on PR #2736:
URL: https://github.com/apache/groovy/pull/2736#issuecomment-5091630102
> There is one point that escapes me right now. Why do we need the hierarchy
at all? I don´t think this is for MetaClassImpl cases.
You are right that this is **not** because `MetaClassImpl` shares one method
table up the hierarchy. Each class still has its own MetaClass / `ClassInfo`
domain.
Hierarchy fan-out exists for **cross-class MOP visibility** that
already-linked subtype sites must re-observe:
1. **Parent ExpandoMetaClass / registry mutation**
`Parent.metaClass.foo = { … }` must force sites linked for `Child` to
re-select so `new Child().foo()` sees the method. Without retiring Child’s
SwitchPoint, a previously linked miss (or older target) stays installed.
2. **Interface MetaClass changes**
Same rule for implementors.
3. **Array covariance**
`Object[]` / interface arrays are MOP-relevant supertypes of reference
arrays even though array classes are `final` — a pure “exact class only” domain
would leave `String[]` sites stale after `Object[]` MetaClass changes.
So: fan-out is about *inherited / covariant MOP state*, not about rewriting
`MetaClassImpl` internals. Category enter/leave remains a separate bulk path
and does not rely on this index for semantics.
**Action taken**
- Documented this rationale on `IndyInvalidation`, `ClassHierarchyIndex`,
and `package-info`.
- Kept / extended tests:
- parent EMC → child SwitchPoint + runtime visibility
- parent `MetaClassImpl` *replacement* still fans out (registry change can
still affect subtype dispatch)
- unrelated-type churn does **not** touch an unrelated hierarchy
- array / interface-array lattice cases (from earlier review)
Happy to discuss a narrower fan-out (e.g. EMC-only) as a follow-up
optimization; the current rule prefers correctness and matches pre-6.0
“something in the MOP above me changed → re-link” behaviour, but scoped to the
subtype cone instead of the whole process.
--
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]
