[
https://issues.apache.org/jira/browse/GROOVY-12215?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=18100379#comment-18100379
]
ASF GitHub Bot commented on GROOVY-12215:
-----------------------------------------
paulk-asert opened a new pull request, #2750:
URL: https://github.com/apache/groovy/pull/2750
…ring DGM methods
Add java.util.function twins beside the Closure overloads of collectMany,
collectingMany, countBy, split, groupBy and takeWhile/dropWhile, in both
DefaultGroovyMethods (collection/map receivers) and ArrayGroovyMethods (array
receivers). Map receivers take BiFunction/BiPredicate; other receivers take
Function/Predicate. Follows the conventions established in GROOVY-12054 (PECS
wildcards, @since 6.0.0, javadoc examples, plain SAM overloads).
32 new overloads (25 in DGM, 7 in ArrayGroovyMethods). The
TakeWhile/DropWhile iterators now hold a Predicate, with the Closure
constructors adapting to it. Regression tests added to LambdasTest.
> Fat-free variants for collectMany, countBy, split, take/dropWhile, groupBy
> --------------------------------------------------------------------------
>
> Key: GROOVY-12215
> URL: https://issues.apache.org/jira/browse/GROOVY-12215
> Project: Groovy
> Issue Type: Sub-task
> Reporter: Paul King
> Assignee: Paul King
> Priority: Major
>
> h3. Summary
> Sub-task of GROOVY-12205. Adds the straightforward "fat-free"
> functional-interface twins — a single {{java.util.function}} overload beside
> each existing {{Closure}} overload — for the mapping/filtering DGM methods
> that currently have none. These are mechanical, following the conventions
> established in GROOVY-12054; no design decisions are involved.
> h3. Methods
> ||Method||Closure overloads without a twin||Functional type||Receivers||
> |{{collectMany}}|8|{{Function<? super E, ? extends Collection<? extends
> T>>}}|Iterable (x2), Map (x2), Iterator (x2), {{E[]}} (x2)|
> |{{collectingMany}}|1|{{Function}} (lazy)|Iterator|
> |{{countBy}}|4|{{Function<? super E, ? extends K>}}|Iterable, Iterator, Map,
> {{E[]}}|
> |{{split}}|5|{{Predicate<? super T>}}|Object, Collection, List, Set, {{T[]}}|
> |{{groupBy}} (single-key)|2|{{Function<? super T, ? extends K>}}|Map,
> {{Object[]}} (the Iterable twin already exists)|
> |{{takeWhile}}|6|{{Predicate<? super T>}}|List, Iterable, SortedSet, Map,
> Iterator, {{T[]}}|
> |{{dropWhile}}|6|{{Predicate<? super T>}}|SortedSet, List, Iterable, Map,
> Iterator, {{T[]}}|
> Total: 32 new overloads.
> h3. Conventions (per GROOVY-12054)
> * PECS wildcards on the functional parameter; {{@since 6.0.0}}.
> * Inline javadoc example using {{<pre class="language-groovy
> groovyTestCase">}}, cross-linking the {{Closure}} counterpart via {{@link}}.
> * Plain single-SAM overloads only — *not* {{@Incubating}}; that annotation is
> reserved for the curried {{(BiXxx, param)}} forms, which are a separate item.
> h3. Exclusions
> * {{groupBy}} multi-key forms ({{Object...}} / {{List<Closure>}}) — no clean
> functional analogue.
> * {{takeWhile}}/{{dropWhile}} on {{CharSequence}}/{{GString}} (the SGM
> char-by-char forms) — a String-domain
> {{Predicate<Character>}}/{{IntPredicate}} decision, out of scope for this
> collection-focused sub-task (keeps the count at 6 each).
> h3. Compatibility
> Existing closure/lambda call sites are unaffected: a {{Closure}} literal
> binds to the {{Closure}} overload, while method references and typed
> functional values select the twin under {{@CompileStatic}} (per
> GROOVY-12214). Only check: an existing {{@CompileStatic}} call passing a
> literal {{null}} to one of these currently-single-overload methods would
> become ambiguous — a rare, grep-checkable case, resolved with a cast if found.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
