Nulls

[Joe Bowbeer]

3 -- if you can pull it off.

If tolerance isn't possible then I'd embrace, ban, and, as a last resort,
ignore.


On Wed, Sep 26, 2012 at 3:13 PM, Kevin Bourrillion <kevinb at google.com>wrote:

> My teammate Colin and I discussed this some and:
>
> On Wed, Sep 26, 2012 at 1:00 PM, Brian Goetz <brian.goetz at oracle.com>wrote:
>
>> 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.
>>
>
> This is more null-hostile than even we'd be comfortable with. Does anyone
> actually back this?
>
>
> 2.  Ignore nulls.
>>
>
> imho, way too surprising. Is anyone backing this?
>
>
>
>> 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.
>>
>
> This is both reasonable and what Guava does.
>
>
> 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'm not sure what exactly this means when I supply a lambda that can't
> handle null. You're saying the NPE thrown by that predicate should be *
> caught* and handled somehow?
>
>
>
>>
>>
>> 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 case
>> 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
>>
>>
>>
>
>
> --
> Kevin Bourrillion | Java Librarian | Google, Inc. | kevinb at google.com
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.openjdk.java.net/pipermail/lambda-libs-spec-experts/attachments/20120926/82489063/attachment-0001.html