David M. Lloyd
david.lloyd at redhat.com
Fri Sep 14 06:15:59 PDT 2012
On 09/14/2012 07:51 AM, Tim Peierls wrote:
> On Fri, Sep 14, 2012 at 8:30 AM, Remi Forax <forax at univ-mlv.fr
> <mailto:forax at univ-mlv.fr>> wrote:
> It's hard to win here. One of the many reasons that we
> are supplying parallel bulk ops for ConcurrentHashMap that
> fall outside the main stream framework is that issue #1 does
> not arise (CHM disallows null keys and values), which
> streamlines many design issues.
> There is in my opinion a better design,
> x = s.findFirst(valueIfEmpty);
> The trouble with that is that I often want to do something different
> depending on whether I found anything, and it is not always easy (or
> even possible) to find a distinct value to use as a sentinel. Rather
> than write ad hoc things like this:
> Result result = filteredResults.findFirst(NO_RESULT);
> if (result != NO_RESULT) ... use result ...
> I prefer being able to write:
> Optional<Result> result = filteredResults.findFirst();
> if (result.isPresent()) ... use result.get() ...
> Note that this preference is less about fluency than preventing user
> errors. It's all too easy to omit the test in the first snippet above,
> but if you try to use result directly in the second snippet without
> testing it, you'll get a compile error.
> I am sensitive to the risk of API pollution by folks who become
> over-enamored of Optional, as Doug hints (e.g., Set<Optional<T>>), but
> the rewards outweigh the risks, IMHO.
I don't know - to me Optional<T> is Pair<A, B>'s brother. Both are
useful, in their way, but both have potential to massively stink up
code. I don't really believe the benefits are worth it - I mean the
best improvement we get isn't an objective "it's faster" or "it allows
more optimal code paths", it's purely a style thing and it does have a
cost. I don't like it; I think it's going to result in things like:
More information about the lambda-libs-spec-experts