Stream proposal and null results

[Brian Goetz]

> I think it would be an interesting idea to inject getOrElse(T) and
> getOrElse(()->T) into Object. They would have wide
> usage beyond the lambdafied collection library.

I agree it is interesting.  Sadly, this is a different kind of extension 
method than we're already doing, since this would have to be a static 
extension method (rewritten by the compiler as a static method call with 
the "receiver" prepended to the argument list) since otherwise calling 
getOrElse on a null instance would throw NPE (calling x.anything on a 
null x throws NPE.)  C# does static extension methods; we're doing 
virtual extension methods.  So this feature is, despite the similarity 
in name, farther from what we're already doing than it might appear.

> With regard to the collection library; I have found a parallel
> collection that does not accept null to be useful, since your maps etc.
> don't need to null check and the collection can use null internally to
> mean skip over item. If the collection didn't hold null, then returning
> null as a sentinel is less problematic.

Yes.  Collections that support nulls are problematic for so many 
reasons.  (Some collections support them; some don't.)  We haven't 
worked out the details, but I like the idea of streams not supporting 
nulls.  (Among other consequences, this makes the null sentinel approach 
not even an option for getFirst.)