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.
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
-
