Streams

[Remi Forax]

On 09/14/2012 01:54 PM, Doug Lea wrote:
> (CCing lambda-libs-spec-experts, which seems better for follow-ups).
>
> On 09/14/12 03:13, Remi Forax wrote:
>> On 09/14/2012 07:23 AM, Sam Pullara wrote:
>>> Here are some issues that I find with the current Streams 
>>> implementation:
>>>
>>> 1) Collection is not a Stream. This means that whenever you use
>>> collections and want to use some of the great new features you have to
>>> first convert it to a stream:
>>>
>>> list.stream().map(l -> parseInt(l)).into(new ArrayList<>())
>>>
>>> I find this unnecessary. Collection could implement Stream and the
>>> default methods could do the conversion for me, probably by calling
>>> .stream() as above.
>>
>> I fuly agree, it will be convenient to have such delegation mechanism.
>
> There's some tension between convenience and sanity here :-)
> I'll let Brian walk through the decision space...
>
>>
>> Is there a document somewhere that explain the pro and cons of using 
>> Optional ?
>> Currently I see it as a way to add a level of indirection with no 
>> real benefit,
>
> I don't think there is a document, but there has been a lot of discussion
> about it  here and there over the years. I think they mainly amount to
> two technical problems, plus at least one style/usage issue:
>
> 1. Some collections allow null elements, which means that you cannot
> unambiguously use null in its otherwise only reasonable sense of "there's
> nothing there".

It's better to never store null and use the null object pattern
if you really want to store the null value.

>
> 2. If/when some of these APIs are extended to primitives, there is
> no value to return in the case of nothing there. The alternative
> to Optional is to return boxed types, which some people would prefer
> not to do.

you can ask user for a default value, see below.

>
> 3. Some people like the idea of using Optional to allow more fluent APIs.
> As in
>   x = s.findFirst().or(valueIfEmpty)
> vs
>   if ((x = s.findFirst()) == null) x = valueIfEmpty;
> Some people are happy to create an object for the sake of
> being able to do this. Although sometimes less happy when they
> realize that Optionalism then starts propagating through their
> designs, leading to Set<Optional<T>>'s and so on.
>
> 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 default value is a parameter of the current function
(see 
https://github.com/forax/lambda-perf/blob/master/lambda-perf/src/perf/Stream.java
if you want to see how it can be implemented).

>
>>> 3) I really, really believe that we should have something around
>>> Future like I have prototyped here:
>
> Right. FutureValue/Promise/whatever is on our todo list for JDK8
> (see JEP 155). One of the many little snags that have held it back
> so far is getting past related issues like Numeric (see my post
> on this).
>
> -Doug
>

Rémi