Remi Forax forax at
Fri Sep 21 05:49:51 PDT 2012

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.


More information about the lambda-libs-spec-observers mailing list