RFR: CSR - JDK-8203428 Predicate::not

forax at univ-mlv.fr forax at univ-mlv.fr
Fri May 18 19:00:37 UTC 2018


Hi Jim,

----- Mail original -----
> De: "Jim Laskey" <james.laskey at oracle.com>
> À: "core-libs-dev" <core-libs-dev at openjdk.java.net>
> Cc: "Remi Forax" <forax at univ-mlv.fr>, "Brian Goetz" <brian.goetz at oracle.com>, "Paul Sandoz" <paul.sandoz at oracle.com>
> Envoyé: Vendredi 18 Mai 2018 20:48:35
> Objet: Re: RFR: CSR - JDK-8203428 Predicate::not

> I’m going to pull a Brian here and say, “not” should stand on its own merits.
> The “of” discussion should diverge to it’s own RFE. :-)

i agree,
sorry to not have been crystal clear, it my head it was clear that that everything i've written was a way to avoid Predicate.of() and not something should stop the inclusion of Predicate.not, stackoverflow has already decided that Predicate.not was the right method [1].

Rémi 

[1] https://stackoverflow.com/questions/21488056/how-to-negate-a-method-reference-predicate

> 
>> On May 18, 2018, at 3:41 PM, Remi Forax <forax at univ-mlv.fr> wrote:
>> 
>> ----- Mail original -----
>>> De: "Brian Goetz" <brian.goetz at oracle.com>
>>> À: "Paul Sandoz" <paul.sandoz at oracle.com>, "Jim Laskey"
>>> <james.laskey at oracle.com>
>>> Cc: "core-libs-dev" <core-libs-dev at openjdk.java.net>
>>> 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 <james.laskey at oracle.com> 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.


More information about the core-libs-dev mailing list