Paul King created GROOVY-12529:
----------------------------------
Summary: 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: Improvement
Components: groovy-macro-library, groovy-typecheckers
Reporter: Paul King
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)
