My sympathies! Eclipse warts and all, Parrot has reduced my frustration
levels about 15% across the board.
On Thu, Apr 29, 2021, 09:50 Milles, Eric (TR Technology) <
eric.mil...@thomsonreuters.com> wrote:
> 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> 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>
> Sent: Wednesday, April 28, 2021 12:07 PM
> To: 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>
> Sent: Wednesday, April 28, 2021 11:36 AM
> To: 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> 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>
> > Sent: Wednesday, April 28, 2021 11:02 AM
> > To: 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> 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>
> > 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?
>
>
>
> --
> Christopher Smith
>
>
