Streams

[David M. Lloyd]

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:

Map<String,Optional<List<Optional<String>>>>

or worse.
-- 
- DML