Nulls

[Joe Bowbeer]

I may want to revisit my statement that Optional cannot contain null:

> But the question really boils down to whether Optional can contain null,
and I don't think it should.

Maybe an Optional that contains null is the right way to differentiate a
null (no element) from a null element.

On Fri, Sep 21, 2012 at 9:26 AM, Joe Bowbeer <joe.bowbeer at gmail.com> wrote:

> It depends on how findFirst is defined.
>
> In groovy, find() returns the first element that satisfies groovy truth,
> and null does not satisfy!  But there is also a find(predicate) where the
> predicate determines what truth is.  (Please excuse the groovy lingo.)
>
> If there is this operation:
>
>     Optional<T> findFirst()
>
> then there should also be a version that takes a Predicate:
>
>     Optional<T> findFirst(Predicate)
>
> and then the question can be rephrased: What is the implicit predicate
> that findFirst() employs?
>
> If the predicate ignores null, then I think it should ignore a few other
> things as well.
>
> But the question really boils down to whether Optional can contain null,
> and I don't think it should.
>
> This leads me to question whether there should be another version of
> findFirst for non-Optional programming.  I find that the two styles don't
> mix well.  Most Java programmers are naturally non-Optional but might want
> to take advantage of Optional.  However, I would tend to use a non-Optional
> findFirst more in Java than not -- because the rest of Java is not
> Optional-friendly.
>
> Joe
>
> On Fri, Sep 21, 2012 at 9:08 AM, Brian Goetz <brian.goetz at oracle.com>wrote:
>
>> Should stream ops be permitted to squeeze out nulls when they don't make
>> sense?
>>
>> For example:
>>
>>   list...findFirst()
>>
>> returns an Optional<T>.  There are good arguments why an Optional should
>> *not* be allowed to contain null.  Should findFirst ignore nulls?  Throw
>> something if the stream begins with null?
>>
>>
>> On 9/21/2012 12:04 PM, Joe Bowbeer wrote:
>>
>>> My position is to support nulls in collections, which leads to
>>> supporting nulls in streams.
>>>
>>> I've never dealt with a popular language that didn't allow nulls --
>>> except for the concurrent flavor of collections in Java, which strikes
>>> me as implementation leaking through into design.
>>>
>>> That said, I don't like nulls, and when I'm using a language like Scala
>>> that allows me to eliminate them, I try to do that, and I feel bad when
>>> I can't.  But I still have nulls in some of my Scala code because it
>>> seems like the right thing in those cases.  Maybe if I were a better
>>> Scala programmer, then I would know of a way to eliminate them in those
>>> cases that would seem even better...
>>>
>>> Btw, I make a distinction with maps and their entries.  Maps don't
>>> contain null mappings, obviously, but I see some leeway regarding what
>>> objects are allowed in the map entries.  For example, I would not allow
>>> null keys, but would allow null values.  I think there's a similar
>>> distinction with streams.  That is, I would allow nulls in streams, but
>>> not null mappings (MapEntry) in MapStreams.
>>>
>>> Joe
>>>
>>> On Fri, Sep 21, 2012 at 8:37 AM, Kevin Bourrillion wrote:
>>>
>>>     On Fri, Sep 21, 2012 at 5:49 AM, Remi Forax wrote:
>>>
>>>         Support them is the only realistic option, there are too many
>>>         codes out there that put null in collections, otherwise it will
>>>         seriously impede the adoption of lambdas.
>>>
>>>
>>>     You would think so, but take a look at how hard Guava is on nulls,
>>>     and we pretty much get away with it.
>>>
>>>     There are always plenty of strategies for fixing your code to not
>>>     need to put nulls into collections, and most of them leave the code
>>>     better off.
>>>
>>>     I'm not taking a position on the issue, just saying the argument
>>>     that we /have/ to support nulls doesn't hold water with me. So
>>>     /what/ if it "impedes adoption" of lambdas a bit? Pleasing everyone
>>>
>>>     all of the time isn't an option anyway.
>>>
>>>
>>>
>