[ 
https://issues.apache.org/jira/browse/GROOVY-12529?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Paul King updated GROOVY-12529:
-------------------------------
        Parent: GROOVY-12528
    Issue Type: Sub-task  (was: Improvement)

> Shared monadic carrier resolver for the DO type checkers and the runtime 
> dispatcher
> -----------------------------------------------------------------------------------
>
>                 Key: GROOVY-12529
>                 URL: https://issues.apache.org/jira/browse/GROOVY-12529
>             Project: Groovy
>          Issue Type: Sub-task
>          Components: groovy-macro-library, groovy-typecheckers
>            Reporter: Paul King
>            Priority: Major
>             Fix For: 7.x
>
>
> "Which carrier is this, and what are its bind and map methods" is answered in 
> five places, using three different hierarchy-matching rules:
> * MonadicChecker.participates: registry, then structural flatMap/map, then 
> @Monadic. Matches via ClassNode isDerivedFrom/implementsInterface.
> * MonadicChecker.trustedCarrierName: registry, then @Monadic.
> * MonadicChecker.bindName (added by GROOVY-12486): registry, then structural 
> flatMap, then @Monadic bind.
> * MonadicShapeChecker.carrierFor: registry only. Matches name-keyed entries 
> via hasInHierarchyByName.
> * Comprehensions.resolveMethodName with MonadicCarrierRegistry.lookupBindMap: 
> registry, then structural, then @Monadic. Matches via a breadth-first walk of 
> the runtime supertypes.
> They agree today, but each new carrier source has to be added to all five, 
> and a registration channel would multiply the risk of divergence.
> Proposal: one resolver with a compile-time (ClassNode) side and a runtime 
> (Class) side, using the same order, the same hierarchy-matching rule and the 
> same single-argument, non-bridge, non-synthetic method filter. All five call 
> sites delegate to it.
> Also decide a deterministic overload rule. A carrier declaring both 
> flatMap(Closure) and flatMap(Function) currently resolves to the first 
> declared method in the checker and the first method returned by 
> Class.getMethods() at runtime.
> Tests: a parity test that feeds the same carrier shapes (Class-keyed, 
> name-keyed via a supertype, structural, @Monadic on a superclass and on an 
> interface, an overloaded bind) through both sides and asserts identical 
> results.



--
This message was sent by Atlassian Jira
(v10.3.26#10030026)

Reply via email to