dl at cs.oswego.edu
Mon Sep 24 04:37:38 PDT 2012
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
> 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.
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
If present Optionals can be null, the world is probably better off
without them; so methods like findAny ONLY take the valueIfNone form.
More information about the lambda-libs-spec-observers