RFR 9: 8138963 : java.lang.Objects new method to default to non-null

[Roger Riggs]

So for you, method overloading is a mis-feature of the language because 
it inhibits readability.
Though I might argue, that the magic type inference is the real culprit.
In most coding cases, the types of the arguments are visible and/or via 
syntax and naming.

Thanks, Roger


On 10/8/2015 2:37 PM, forax at univ-mlv.fr wrote:
> Hi Roger,
> my point was that for me, all theses forms are ambiguous thus not 
> readable.
>
>     *De: *"Roger Riggs" <Roger.Riggs at Oracle.com>
>     *À: *"Remi Forax" <forax at univ-mlv.fr>
>     *Cc: *"core-libs-dev" <core-libs-dev at openjdk.java.net>
>     *Envoyé: *Jeudi 8 Octobre 2015 16:44:54
>     *Objet: *Re: RFR 9: 8138963 : java.lang.Objects new method to
>     default to non-null
>
>     Hi Remi,
>
>     On 10/8/2015 4:49 AM, Remi Forax wrote:
>
>         Hi Roger,
>         using overloads here seems to be a bad idea,
>         as a nice puzzler, what does the compiler do for these two lines of code
>            Supplier<String> supplier = Objects.nonNullOf(null, () -> null);
>            Supplier<String> supplier2 = Objects.nonNullOf(null, () -> "");
>
>     The first form compiled and threw the expected NPE at runtime.
>
>
> I'm not sure you can say this is the expected result. Why the compiler 
> doesn't call <T> T nonNullOf(T, T) and return () -> null as Supplier ?
>
>
>
>     In the second case, the () -> "" is a supplier<String> not a
>     Supplier<Supplier<String>>.
>     The compiler correctly produced a error. 
>
>
> Why the compiler doesn't select the method <T> T nonNullOf(T, T) 
> instead, this version compiles !
>
> and if you want more weirdness, what about ?
>   Object o = Objects.nonNullOf"foo", null);
>
>
>
>     I don't think the method name will help the developer much and
>     just makes the name longer
>     for everyone else who is not producing a Supplier<Supplier<T>>.
>
>
> maybe "nonNullOfGet" is a bad name, my point is that when you have 
> several overloads like this, the result is not easy to predict (I 
> suppose that people don't know by heart the chapter 15.12.2 of the JLS).
>
> [...]
>
>
>     Thanks, Roger
>
>
> regards,
> Rémi
>
>
>
>         otherwise apart form the remark of Stephen, the code is Ok.
>
>         cheers,
>         Rémi
>            
>
>         ----- Mail original -----
>
>             De: "Roger Riggs"<Roger.Riggs at Oracle.com>
>             À: "core-libs-dev"<core-libs-dev at openjdk.java.net>
>             Envoyé: Jeudi 8 Octobre 2015 00:24:26
>             Objet: Re: RFR 9: 8138963 : java.lang.Objects new method to default to	non-null
>
>             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
>
>                 -
>
>
>