This would be both expensive and problematic with static mode, which is
what I use almost exclusively for production code.
On Tue, Apr 27, 2021, 20:26 Remi Forax <fo...@univ-mlv.fr> wrote:
> ----- Mail original -----
> > De: "Christopher Smith" <chrylis+gro...@gmail.com>
> > À: "dev" <dev@groovy.apache.org>
> > Envoyé: Mercredi 28 Avril 2021 01:37:14
> > Objet: 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?
>
> It may be simpler to have a conversion from any instance of a functional
> interface to a Closure,
> with closure.call() calling the abstract method of the functional
> interface.
>
> This will require to check at runtime if a class implement a functional
> interface, to wrap the instance in a Closure.
> It would be cool if the annotation @FunctionalInterface was declared with
> a retention RUNTIME, so the check to know if an instance is a lambda or not
> will be easy.
> But wait, it's already the case, someone thought about that in the lambda
> expert group :)
>
> Rémi
>
