tim at peierls.net
Sat Sep 22 09:43:21 PDT 2012
On Sat, Sep 22, 2012 at 11:02 AM, Brian Goetz <brian.goetz at oracle.com>wrote:
> 1. Stream operations ignore null elements.
> This interacts in an unfortunate way with a property I've been fighting to
> preserve -- size-preserving ops. ...
> So I prefer to interpret your suggestion as "*may* ignore null elements".
> So in this case, a reduction can ignore nulls, a find can ignore nulls,
> but "dense" ops can choose not to.
I'd hate to have to put null checks in mapping functions, though. How about
just "size-preserving in the absence of nulls"? I think of nulls as a case
to be allowed but not encouraged.
> This gets confusing for reduce, since currently we have:
> T reduce(T base, Reducer<T>) // trying not to upset Doug by
> Optional<T> reduce(Reducer<T>) // saying BinaryOperator<T>
> If we add a
> T reduce(Reducer<T>, T defaultValueIfNone)
> the user will forever be confused between the first form and the third.
Can we really not find a way to pick just one of the first and third forms?
Yes, I realize there is a subtle difference between "base" and
"defaultValueIfNone", but I'm having trouble coming up with a realistic way
to be bitten by this.
(Shouldn't the default value come first, btw, to allow the remaining args
to end with a varargs?)
More information about the lambda-libs-spec-observers