joe.bowbeer at gmail.com
Fri Sep 21 09:04:29 PDT 2012
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.
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.
More information about the lambda-libs-spec-observers