Nulls

[Remi Forax]

On 09/17/2012 05:08 PM, Brian Goetz wrote:
> On 9/15/2012 10:24 AM, Doug Lea wrote:
>
>> To further rub in how central the "little" issues of optional/null,
>> (as well as numerics) are in all this, note that flatMap is just a
>> special form of mapReduce(x->coll, addAll)
>
> and filter() is just a special form of flatMap
>
>> , which can be
>> implemented so as to require a basis/default policy
>> only if there is nothing there, so could do one of:
>> (1) return null (2) accept an empty-collection generator as
>> basis/defaultValue arg (3) return Optional (4) factor into
>> a special flatMapper interface that absorbs the problem
>> (as Brian chose; in CHM, I support unified forms of map+Reduce
>> explicitly, which leverages intrinsic null policy to naturally use
>> option #1, so method flatMap does not even appear.
>
> We keep circling round the question of what to do about null values in 
> streams.  Are they supported?  Banned?  Grumblingly tolerated?
>
> As Doug points out, for concurrent collections, the sensible way to 
> interpret null is "there's nothing there right now."  But, given that 
> the streams API is built around an assumption of non-interference, we 
> don't have to worry about "right now" as much; the contents of the 
> stream source should remain constant during the course of the 
> calculation.
>
> If we'd bitten the bullet and not allowed nulls as elements in 
> Collections from the beginning, we'd have less of a problem now.
>
> So, looking at only the sequential case right now, what are the 
> realistic options for handling nulls in streams?
>

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.

Rémi