The "side by side" approach is my second option; the only significant downside is an increase in the surface area of the extension landscape. I think Jochen excellently described the distinction of some cases (`with`) where Closure awareness is still needed for reasons of delegate manipulation, and in these cases adding a Function signature (essentially a "map" operation) would make more sense.
To be frank, I can't see a good reason for saying that `collect` (e.g.) should just be given up in preference to an explicit stream. In such a case, there is no disadvantage whatsoever that I can see to trimming the GDK signature back to the more vanilla functional interface and interpreting a Closure as that interface when desired, as is already done for interop everywhere else. On Wed, Apr 28, 2021, 09:22 Milles, Eric (TR Technology) < eric.mil...@thomsonreuters.com> wrote: > 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? >
