[
https://issues.apache.org/jira/browse/GROOVY-12722?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Scott Murphy Heiberg updated GROOVY-12722:
------------------------------------------
Description:
{{Collection.sum()}} adds the elements, and {{sum(Closure)}} adds the
transformed elements. {{ParallelCollectionExtensions.sumParallel(Collection<T>,
BinaryOperator<T>)}} is a reduction with a required two-argument combiner
(GPars' {{sumParallel()}} took no argument; the migration guide maps it to the
two-parameter closure form, sumParallel { a, b -> a + b }, and notes that the
accumulator is required). Code written by analogy with {{sum}} fails:
{code:groovy}
@CompileStatic
int total(List<Integer> numbers) {
numbers.sumParallel { Integer n -> n }
}
{code}
{noformat}
[Static type checking] - Wrong number of parameters for method target:
apply(java.lang.Integer, java.lang.Integer)
{noformat}
and in dynamic code items.sumParallel { it.price } calls the one-parameter
closure with two arguments.
Proposal, additive:
* {{sumParallel(Collection<?> self)}}: the elements added with the left
operand's {{plus}}, as {{sum()}} does; an empty collection gives null.
* {{<T, R> R sumParallel(Collection<T> self, Closure<R> closure)}} with
{{@ClosureParams(value = FromString, options = ["T", "T,T"])}}: a one-parameter
closure is a transform and the transformed elements are added, the
{{sum(Closure)}} contract; a two-parameter closure stays the combiner, so
existing calls keep working and, under static compilation, keep their result
type. The {{BinaryOperator}} overload stays for method references and Java
callers.
* {{CombinerChecker}} (GROOVY-12013) leaves a one-parameter closure alone: it
is not a combiner.
* core-parallel-collections.adoc and the GPars migration table show the three
forms.
Found while scoring Groovy 6.0.0 code written by language models: with the
parallel-collections skill text in front of it, GPT-6 still wrote the
one-parameter form.
was:
{{Collection.sum()}} adds the elements, and {{sum(Closure)}} adds the
transformed elements. {{ParallelCollectionExtensions.sumParallel(Collection<T>,
BinaryOperator<T>)}} is a reduction with a required two-argument combiner
(GPars' {{sumParallel()}} took no argument; the migration guide maps it to
{{sumParallel \{ a, b -> a + b \}}} and notes that the accumulator is
required). Code written by analogy with {{sum}} fails:
{code:groovy}
@CompileStatic
int total(List<Integer> numbers) {
numbers.sumParallel { Integer n -> n }
}
{code}
{noformat}
[Static type checking] - Wrong number of parameters for method target:
apply(java.lang.Integer, java.lang.Integer)
{noformat}
and in dynamic code {{items.sumParallel \{ it.price \}}} calls the
one-parameter closure with two arguments.
Proposal, additive:
* {{sumParallel(Collection<?> self)}}: the elements added with the left
operand's {{plus}}, as {{sum()}} does; an empty collection gives null.
* {{<T, R> R sumParallel(Collection<T> self, Closure<R> closure)}} with
{{@ClosureParams(value = FromString, options = ["T", "T,T"])}}: a one-parameter
closure is a transform and the transformed elements are added, the
{{sum(Closure)}} contract; a two-parameter closure stays the combiner, so
existing calls keep working and, under static compilation, keep their result
type. The {{BinaryOperator}} overload stays for method references and Java
callers.
* {{CombinerChecker}} (GROOVY-12013) leaves a one-parameter closure alone: it
is not a combiner.
* core-parallel-collections.adoc and the GPars migration table show the three
forms.
Found while scoring Groovy 6.0.0 code written by language models: with the
parallel-collections skill text in front of it, GPT-6 still wrote the
one-parameter form.
> sumParallel: add the no-argument and transform forms of sum(); the combiner
> form reads as inject
> ------------------------------------------------------------------------------------------------
>
> Key: GROOVY-12722
> URL: https://issues.apache.org/jira/browse/GROOVY-12722
> Project: Groovy
> Issue Type: Improvement
> Affects Versions: 6.0.0
> Reporter: Scott Murphy Heiberg
> Priority: Major
>
> {{Collection.sum()}} adds the elements, and {{sum(Closure)}} adds the
> transformed elements.
> {{ParallelCollectionExtensions.sumParallel(Collection<T>,
> BinaryOperator<T>)}} is a reduction with a required two-argument combiner
> (GPars' {{sumParallel()}} took no argument; the migration guide maps it to
> the two-parameter closure form, sumParallel { a, b -> a + b }, and notes that
> the accumulator is required). Code written by analogy with {{sum}} fails:
> {code:groovy}
> @CompileStatic
> int total(List<Integer> numbers) {
> numbers.sumParallel { Integer n -> n }
> }
> {code}
> {noformat}
> [Static type checking] - Wrong number of parameters for method target:
> apply(java.lang.Integer, java.lang.Integer)
> {noformat}
> and in dynamic code items.sumParallel { it.price } calls the one-parameter
> closure with two arguments.
> Proposal, additive:
> * {{sumParallel(Collection<?> self)}}: the elements added with the left
> operand's {{plus}}, as {{sum()}} does; an empty collection gives null.
> * {{<T, R> R sumParallel(Collection<T> self, Closure<R> closure)}} with
> {{@ClosureParams(value = FromString, options = ["T", "T,T"])}}: a
> one-parameter closure is a transform and the transformed elements are added,
> the {{sum(Closure)}} contract; a two-parameter closure stays the combiner, so
> existing calls keep working and, under static compilation, keep their result
> type. The {{BinaryOperator}} overload stays for method references and Java
> callers.
> * {{CombinerChecker}} (GROOVY-12013) leaves a one-parameter closure alone: it
> is not a combiner.
> * core-parallel-collections.adoc and the GPars migration table show the three
> forms.
> Found while scoring Groovy 6.0.0 code written by language models: with the
> parallel-collections skill text in front of it, GPT-6 still wrote the
> one-parameter form.
--
This message was sent by Atlassian Jira
(v10.3.26#10030026)
