Nulls

[Joe Bowbeer]

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.
>>
>>
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.openjdk.java.net/pipermail/lambda-libs-spec-experts/attachments/20120921/fbf598f3/attachment.html