Donald.Raab at gs.com
Thu Sep 27 06:19:56 PDT 2012
3 seems the most reasonable option to me.
> -----Original Message-----
> From: lambda-libs-spec-experts-bounces at openjdk.java.net [mailto:lambda-
> libs-spec-experts-bounces at openjdk.java.net] On Behalf Of Brian Goetz
> Sent: Wednesday, September 26, 2012 4:01 PM
> To: lambda-libs-spec-experts at openjdk.java.net
> Subject: Nulls
> Trying again to categorize the choices and identify pros/cons...
> Seems like there are four buckets here:
> 1. Ban nulls. This means that feeding nulls into a Stream MUST
> produce an NPE.
> 2. Ignore nulls.
> 3. Tolerate nulls. Streams API takes no position on nulls, but may
> well pass elements to less tolerant destinations (e.g., user-provided
> lambdas, user-provided collections, Optional constructor.) Nulls may
> cause NPEs in these cases.
> 4. Embrace nulls. Ensure that every operation can deal with nulls in
> a well-defined manner. (This entails, for example, either dropping the
> Optional-bearing methods or making present Optional deal with null.)
> I think its safe to say that for each of these, there is some subset of
> us who finds it undesirable.
> Doug proposed (2) and (4). I proposed (3). Nearly everyone has some
> sympathy for (1) but no one really wants to be that intolerant.
> Attempted summary of pros/cons:
> 1 PRO: Predictable, simple
> 1 CON: Might be overly harsh, interferes with when user might actually
> want to see nulls and can deal accordingly
> 2 PRO: Simple
> 2 CON: size() lies, interferes with optimizations, interferes with when
> user might actually want to see nulls and can deal accordingly
> 3 PRO: Minimizes distortion on API, implementation in the null-free
> 3 CON: more complex reasoning about what might happen, op behavior may
> change subtly over time as implementation changes
> 4 PRO: Predictable
> 4 CON: sacrifices functionality/safety for sake of a corner case
More information about the lambda-libs-spec-observers