forax at univ-mlv.fr
Fri Sep 14 05:30:19 PDT 2012
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
>>> 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)
> 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
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).
More information about the lambda-libs-spec-experts