Is there any reason that these cannot exist side-by-side as extension methods?
If they are safe to co-exist, then you can create each of the alternatives in
turn within a sample project and try them out. The extension method mechanism
is open and available.
public static <S,T> List<T> collect(Iterable<S> self,
@ClosureParams(FirstParam.FirstGenericType.class) Closure<T> transform)
public static <S,T> List<T> collect(Iterable<S> self, Function<? super
S, ? extends T> transform)
Otherwise, I think the going advice is to use Java streams if you want a
lambda/method reference friendly API. There is an ticket in JIRA about making
streams a bit more "groovy": https://issues.apache.org/jira/browse/GROOVY-10026
-----Original Message-----
From: Christopher Smith <chrylis+gro...@gmail.com>
Sent: Tuesday, April 27, 2021 6:37 PM
To: dev@groovy.apache.org
Subject: GDK retrofit for Java functional interfaces
Since Paul is now threatening us with a 4.0 beta, I wanted to float an idea
that I've been thinking over for a bit now that might be best to add there
(though maybe it would be okay in 3 still, with the Java 8 baseline).
A large number of the GDK extension methods (particularly stuff like `with`,
`collect`, and similar) have signatures that rely explicitly on Closure for
their strategies. This means that there are interoperability problems with
libraries that provide strategy implementations as functional types; e.g.,
imagine this trivial
example:
```
public UnaryOperator<Integer> multiplier(int multiplicand) {
return x -> x * multiplicand;
}
```
I can't say `[1, 2, 3].collect(multiplier(2))`, because `collect` takes only a
Closure.
I would like to (ideally) alter the signatures of the methods in
DefaultGroovyMethods and similar to replace Closure with the "more static"
interfaces where possible; most of these cases would end up being Function,
Consumer, and some of the other usual suspects, with some of the extension
methods being duplicated to account for the cases where the GDK currently does
runtime magic like arity detection.
In the alternative, at least adding overrides for these would support
language-level interoperability.
What is the opinion regarding making this change, and what kinds of
compatibility problems might result from replacing Closure with (e.g.) Function
rather than adding a new override?
