Nulls

[Doug Lea]

On 09/22/12 08:25, Remi Forax wrote:
> On 09/22/2012 02:00 PM, Doug Lea wrote:
>> 1. Stream operations ignore null elements.
>> 2. Each operation that can return a "nothing there" result has two forms
>>    Optional<T> op(...)
>>    T op(..., T defaultValueIfNone);
>
> The main issue with rule 1 is that the JDK already uses meaningful null,
> by example, a class with a null classloader doesn't mean that there is no
> classloader.
>
>    List<Class<?>> list = ...
>    Maps<Class<?>, ClassLoader> classLoadedMap =
>      list.mapped(Class::getClassLoader).into(new HashMap<>());
>
> so Optional should be able to store null.

This is how all these discussions seem to go: Some existing
or potential abuse of null leads to rules allowing further
abuse. Every time I lose the straight "null means nothing there"
argument, I figure that I'm complicit in adding a few million
dollars to Hoare's billion dollar mistake.
(http://www.infoq.com/presentations/Null-References-The-Billion-Dollar-Mistake-Tony-Hoare
;
http://mattcallanan.blogspot.com/2010/09/tony-hoare-billion-dollar-mistake.html)

At least in j.u.c, we pretty much fixed this (although even there
I got talked into allowing nulls in the ConcurrentMap interface,
but still disallow them in all j.u.c map implementations. Weird.)

>
> rule 2 is in my opinion a good compromise if by default the method that returns
> an Optional is written using the method that takes a default value as last
> parameter.

If present Optionals can be null, the world is probably better off
without them; so methods like findAny ONLY take the valueIfNone form.

-Doug