blackdrag commented on PR #2736:
URL: https://github.com/apache/groovy/pull/2736#issuecomment-5135065448
> ### Short answer
>
> Hierarchy SwitchPoint fan-out is needed in **one** live-selection
situation only:
>
> > The **receiver’s MetaClass is unchanged**, selection previously linked a
result that depended on an **ancestor** modified `MutableMetaClass` (almost
always EMC) via the **missing-method** walk
(`MetaClassImpl.findMethodInClassHierarchy`), and that ancestor later **gains
or loses** methods that change the walk’s result.
[...]
> 4. **The case that _does_ need hierarchy SP** (what the machinery is
for):
>
> ```groovy
> class Parent {}
> class Child extends Parent {}
> def call(x) {
> try { x.onlyOnParent(); 'hit' }
> catch (MissingMethodException e) { 'miss' }
> }
> def c = new Child()
> assert call(c) == 'miss' // monomorphic miss linked on Child
> Parent.metaClass.onlyOnParent = { -> 'now-visible' }
> assert call(c) == 'hit' // must re-select; Child MetaClass
unchanged
> ```
Does this single MissingMethodException case really justify the SwitchPoint
usage? Are we even caching in that case? If we are then caching that would be
new in this pull request I assume. And in that case I would question that
decision.
[...]
> The _feature_ is small in description (missing-method hierarchy + EMC),
not quite, it is: missing-method hierarchy + EMC + MissingMethodException +
Method exists later. That is a lot smaller. How often does this appear in a
typical code base in for example Grails? @paulk-asert maybe you can help here
in answering that? I simply think that the hierarchy is overkill for this and a
simple uncached path through the metaclass would be sufficient. If I oversee
something here, I would love for you to correct me. Switchpoints add overhead
too.
--
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]
