----- Mail original ----- > De: "Brian Goetz" <[email protected]> > À: "Paul Sandoz" <[email protected]>, "Jim Laskey" > <[email protected]> > Cc: "core-libs-dev" <[email protected]> > Envoyé: Vendredi 18 Mai 2018 20:08:42 > Objet: Re: RFR: CSR - JDK-8203428 Predicate::not
> We did discover that default methods on FIs combined with subtyping of > FIs caused trouble. But static methods are fine. > > If we're going to do Xxx.of(...), we should do it uniformly across FIs, > not just for Predicate. I think this is a reasonable move, but we don't > have to do it right now. (The benefit is mostly that we pick up > inference of the type parameters.) we can also: - allow diamond syntax on cast - teach the inference that when a method is called on a method reference, it's maybe an automorphism, so the target type could be back-propagated as the target type of the method reference and then the method can be checked from left to right (it's maybe too magical but it seems to work great in practice) - when inference fails, pick the closest interface from java.util.function to the function type, i.e we abandon the idea to introduce real function type in the future for more convenience. regards, Rémi > > On 5/18/2018 1:54 PM, Paul Sandoz wrote: >> >>> On May 18, 2018, at 9:35 AM, Jim Laskey <[email protected]> wrote: >>> >>> Introduce a new static method Predicate::not which will allow developers to >>> negate predicate lambdas trivially. >>> >>> >>> csr: https://bugs.openjdk.java.net/browse/JDK-8203428 >> >> +1 thank you for taking action on this. >> >> Predicate not captures the majority use case very concisely and clearly. >> >> I am reluctant to go for an alternative or companion Predicate.of, and would >> need to think carefully about that idiom and it's application on other >> functional interfaces (perhaps we went too far adding such default methods to >> these interfaces…). >> > > Paul.
