RFR 9: 8138963 : java.lang.Objects new method to default to non-null
Ivan Gerasimov
ivan.gerasimov at oracle.com
Thu Oct 8 16:40:03 UTC 2015
On 08.10.2015 19:33, Roger Riggs wrote:
> Hi Ivan,
>
> It was there, for compile time, to confirm the type signature of the
> return value;
> the type checking on == isn't as strong as assignment.
Ah, Okay. Thanks for explanation!
Sincerely yours,
Ivan
> But it would not be needed more than once.
>
> Roger
>
>
>
> On 10/8/2015 12:13 PM, Ivan Gerasimov wrote:
>> Hi Roger!
>>
>> In the test, why the 'result' variable is needed?
>>
>> 242 String result;
>> 243 errors += (result = Objects.nonNullOf(nullString,
>> defString)) == defString ? 0 : 1;
>> 244 errors += (result = Objects.nonNullOf(nonNullString,
>> defString)) == nonNullString ? 0 : 1;
>> 245 errors += (result = Objects.nonNullOf(nonNullString,
>> null)) == nonNullString ? 0 : 1;
>>
>> I don't see its value being used anywhere.
>>
>> Sincerely yours,
>> Ivan
>>
>> On 08.10.2015 1:24, Roger Riggs wrote:
>>> Hi,
>>>
>>> The original intent was to simplify the filling in of default values
>>> (even if null).
>>> I took Remi's point about the canonical coalescing operator not
>>> always returning non-null
>>> but the push seems to be in the direction of making sure the result
>>> is always non-null.
>>> I'd rather add a few very useful methods and avoid those with
>>> diminishing returns.
>>>
>>> I note that nulls are discovered eventually, but doing more
>>> aggressive checking is preferred.
>>> I expect the compiler is able to squeeze out all the extra checks.
>>>
>>> In the current context of Objects that the jdk, I read the naming
>>> pattern of firstNonNull to imply
>>> access to some sequential data structure like an array or list; but
>>> it doesn't gel with me to apply it to the arg list
>>> (unless it was varargs). The pattern of naming us "of" as being
>>> factory producing an object
>>> from the arguments seems apropos and is concise.
>>>
>>> Please consider and comment:
>>>
>>> <T> T nonNullOf(T obj, T defaultObj);
>>> <T> T nonNullOf(T, obj, Supplier<T> defaultSupplier);
>>>
>>> Details are in the updated webrev:
>>> http://cr.openjdk.java.net/~rriggs/webrev-object-non-null/
>>>
>>> Regards, Roger
>>>
>>>
>>> On 10/6/2015 6:42 PM, Remi Forax wrote:
>>>> Null coalescing is a popular operator in several languages [1] and
>>>> the usual semantics is nullOrElse and not firstNonNull.
>>>> In languages like Kotlin or Swift, because there is a distinction
>>>> between Object and Object?, it's not a big deal, you can not
>>>> de-reference null by error, anyway.
>>>>
>>>> Also note that nullOrElseGet, the one that takes a supplier also
>>>> exists in Groovy and Kotlin under the name null safe navigation.
>>>>
>>>> So even if i prefer the semantics of firstNonNull, i think we
>>>> should also include both nullOrElse and nullOrElseGet.
>>>>
>>>> regards,
>>>> Rémi
>>>>
>>>> [1] https://en.wikipedia.org/wiki/Null_coalescing_operator
>>>>
>>>> -
>>>
>>>
>>
>
More information about the core-libs-dev
mailing list