Understood. Just wanted to make note of something anyone could use now. New extension methods may only be available in Groovy 4. Myself, I'm still stuck on Groovy 2.5 and I get tickets all the time about keeping Groovy 2.4 supported.
From: Christopher Smith <chry...@gmail.com> Sent: Thursday, April 29, 2021 9:37 AM To: dev@groovy.apache.org Subject: Re: GDK retrofit for Java functional interfaces Yup, those workarounds are effective, but they essentially consist in wrapping the cheap functional interface into an expensive closure even when there's no value-add. The inverse approach of defining the API to take the interface and making the closure implement it requires handling that's already necessary for interop and is lightweight by default. On Thu, Apr 29, 2021, 09:33 Milles, Eric (TR Technology) <eric.mil...@thomsonreuters.com<mailto:eric.mil...@thomsonreuters.com>> wrote: Here are two alternatives that should work right now: UnaryOperator<Integer> multiplier(int multiplicand) { return x -> x * multiplicand; } List<Integer> list = [1, 2, 3] list.collect(multiplier(2)) // fails list.collect(multiplier(2).&apply) list.collect(this.&miltiplier.curry(2)) -----Original Message----- From: Milles, Eric (TR Technology) <eric.mil...@thomsonreuters.com<mailto:eric.mil...@thomsonreuters.com>> Sent: Wednesday, April 28, 2021 12:07 PM To: dev@groovy.apache.org<mailto:dev@groovy.apache.org> Subject: RE: GDK retrofit for Java functional interfaces It is best IMO to open a JIRA ticket first so that discussion and metadata can be tracked. Beyond that, opening a pull request on github with a link back to the ticket should suffice. The ticket prevents surprise when a pull request shows up. And I'd suggest starting with a small change first. -----Original Message----- From: Christopher Smith <chry...@gmail.com<mailto:chry...@gmail.com>> Sent: Wednesday, April 28, 2021 11:36 AM To: dev@groovy.apache.org<mailto:dev@groovy.apache.org> Subject: Re: GDK retrofit for Java functional interfaces My case for `with` and `tap` is that in both cases they're immensely useful as general pipeline operations, and being able* to use `with(Foo::transform)` but not `with(Foo.transform(param))` is inconsistent and has been an in-real-use frustration for my current project. Where the Closure is explicitly manipulated it certainly makes sense to keep that overload first-class. What's the Apache process for doing this? I know how to open a ticket (heh), but can I just open a GitHub PR against apache/groovy? Looks like putting GROOVY-ABCD in the commit summary will auto-link it. On Wed, Apr 28, 2021 at 11:19 AM Milles, Eric (TR Technology) <eric.mil...@thomsonreuters.com<mailto:eric.mil...@thomsonreuters.com>> wrote: > > For any DGM that accepts Closure but does not use closure delegation or > multiple closure param signatures, we could mark the Closure version > deprecated and add an @FunctionalInterface equivalent. Existing code that > uses closure literals or method pointers should be okay. There may be one or > two edge cases out there. > > > > For the ones that use delegation like "with" and "tap" I don't think there is > a strong case for making a change. > > > > I think it would probably be best to submit one JIRA ticket for each group of > methods. That is, one for "collect", one for "findAll", etc. So we can > break the problem down and test things a little at a time. > > > > From: Christopher Smith <chry...@gmail.com<mailto:chry...@gmail.com>> > Sent: Wednesday, April 28, 2021 11:02 AM > To: dev@groovy.apache.org<mailto:dev@groovy.apache.org> > Subject: Re: GDK retrofit for Java functional interfaces > > > > 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<mailto: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://nam02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fissu > es.apache.org<https://nam02.safelinks.protection.outlook.com/?url=http%3A%2F%2Fes.apache.org%2F&data=04%7C01%7Ceric.milles%40thomsonreuters.com%7Cbae536ea0813478e1d9b08d90b1c525a%7C62ccb8646a1a4b5d8e1c397dec1a8258%7C0%7C0%7C637553038537492664%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=ukSnBwNw%2BuJk4e5Ap1y%2FXC58UpYr0PVqXH7k%2B9Y1Npw%3D&reserved=0>%2Fjira%2Fbrowse%2FGROOVY-10026&data=04%7C01%7Ceric.m > illes%40thomsonreuters.com<https://nam02.safelinks.protection.outlook.com/?url=http%3A%2F%2F40thomsonreuters.com%2F&data=04%7C01%7Ceric.milles%40thomsonreuters.com%7Cbae536ea0813478e1d9b08d90b1c525a%7C62ccb8646a1a4b5d8e1c397dec1a8258%7C0%7C0%7C637553038537502649%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=QMxCO1V2sMkSPMS3phcGwlv2TAT1qPXyNZo8UWQFHm0%3D&reserved=0>%7Cd2fd247908f84786338b08d90a63bc3c%7C62ccb8 > 646a1a4b5d8e1c397dec1a8258%7C0%7C0%7C637552245742549051%7CUnknown%7CTW > FpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6 > Mn0%3D%7C1000&sdata=TTaemEkQLuQ7uTXXMdA%2Fjgx2%2BJMxMg%2BnpBgqImKL > fCI%3D&reserved=0 > > > -----Original Message----- > From: Christopher Smith > <chrylis+gro...@gmail.com<mailto:chrylis%2bgro...@gmail.com>> > Sent: Tuesday, April 27, 2021 6:37 PM > To: dev@groovy.apache.org<mailto: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? -- Christopher Smith
