lambda-libs-spec-observers Digest, Vol 8, Issue 30
Jose
jgetino at telefonica.net
Sat Apr 20 16:41:33 PDT 2013
-----Mensaje original-----
De: lambda-libs-spec-observers-bounces at openjdk.java.net
[mailto:lambda-libs-spec-observers-bounces at openjdk.java.net] En nombre de
lambda-libs-spec-observers-request at openjdk.java.net
Enviado el: domingo, 21 de abril de 2013 0:39
Para: lambda-libs-spec-observers at openjdk.java.net
Asunto: lambda-libs-spec-observers Digest, Vol 8, Issue 30
Send lambda-libs-spec-observers mailing list submissions to
lambda-libs-spec-observers at openjdk.java.net
To subscribe or unsubscribe via the World Wide Web, visit
http://mail.openjdk.java.net/mailman/listinfo/lambda-libs-spec-observers
or, via email, send a message with subject or body 'help' to
lambda-libs-spec-observers-request at openjdk.java.net
You can reach the person managing the list at
lambda-libs-spec-observers-owner at openjdk.java.net
When replying, please edit your Subject line so it is more specific
than "Re: Contents of lambda-libs-spec-observers digest..."
Today's Topics:
1. Re: Varargs stream factory methods (Remi Forax)
2. Drop Arrays.parallelStream()? (Brian Goetz)
3. Re: Drop Arrays.parallelStream()? (Mike Duigou)
4. Re: Drop Arrays.parallelStream()? (Tim Peierls)
5. Re: Drop Arrays.parallelStream()? (Joe Bowbeer)
6. Re: Drop Arrays.parallelStream()? (Brian Goetz)
7. Re: Drop Arrays.parallelStream()? (Brian Goetz)
----------------------------------------------------------------------
Message: 1
Date: Sat, 20 Apr 2013 22:38:28 +0200
From: Remi Forax <forax at univ-mlv.fr>
Subject: Re: Varargs stream factory methods
To: lambda-libs-spec-experts at openjdk.java.net
Message-ID: <5172FCC4.5030403 at univ-mlv.fr>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
On 04/20/2013 07:02 PM, Sam Pullara wrote:
> I like the .of() idea better than overloading .stream().
>
> Sam
I agree,
'of' is already used in EnumSet for that purpose.
R?mi
>
> On Apr 20, 2013, at 8:47 AM, Brian Goetz <brian.goetz at oracle.com> wrote:
>
>> Currently we have, in Arrays:
>>
>> public static <T> Stream<T> stream(T[] array) {
>> return stream(array, 0, array.length);
>> }
>>
>> public static IntStream stream(int[] array) {
>> return stream(array, 0, array.length);
>> }
>>
>> etc.
>>
>> We *could* make these varargs methods, which is useful as creating ad-hoc
stream literals:
>>
>> Arrays.stream(1, 2, 4, 8).map(...)
>>
>> The downside is that we would have to lose (or rename) methods like:
>>
>> public static IntStream stream(int[] array,
>> int fromIndex, int toIndex) {
>>
>> since stream(1, 2, 3) would be ambiguous.
>>
>> Probably better, make these static factories in the various stream
interfaces:
>>
>> Stream.of("foo", "bar")
>>
>> IntStream.of(1, 2, 4, 8)
>>
------------------------------
Message: 2
Date: Sat, 20 Apr 2013 17:47:49 -0400
From: Brian Goetz <brian.goetz at oracle.com>
Subject: Drop Arrays.parallelStream()?
To: "lambda-libs-spec-experts at openjdk.java.net"
<lambda-libs-spec-experts at openjdk.java.net>
Message-ID: <51730D05.5030007 at oracle.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
We dropped the parallel versions of all the static generator/factory
methods in Streams a while ago, in favor of just letting people do (say)
IntStream.range(...).parallel(). Since then, we have also greatly
reduce the runtime cost of Stream.parallel().
We still have the separate .parallelStream() method on Collection and in
the static methods in Arrays.
I still really like Collection.parallelStream; it has huge
discoverability advantages, and offers a pretty big return on API
surface area -- one more method, but provides value in a lot of places,
since Collection will be a really common case of a stream source.
Arrays are in a middle ground. We have eight Arrays.stream() methods
and eight Arrays.parallelStream() methods (four types, both whole-array
and slice versions). I'm having a bit of a YAGNI twinge for the
Arrays.parallelStream forms, and could see ditching them. (The
implementations are trivial and small, so that is not an argument to
ditch them -- we should make this decision purely on API considerations.)
If we did this, Collection would have the sole parallelStream method;
everything else would have to go through .parallel(). Which seems fine
to me.
------------------------------
Message: 3
Date: Sat, 20 Apr 2013 15:01:29 -0700
From: Mike Duigou <mike.duigou at oracle.com>
Subject: Re: Drop Arrays.parallelStream()?
To: lambda-libs-spec-experts at openjdk.java.net
Message-ID: <D3C4D46C-5495-4D26-A5E1-8084A06972AC at oracle.com>
Content-Type: text/plain; charset=iso-8859-1
On Apr 20 2013, at 14:47 , Brian Goetz wrote:
> We dropped the parallel versions of all the static generator/factory
methods in Streams a while ago, in favor of just letting people do (say)
IntStream.range(...).parallel(). Since then, we have also greatly reduce
the runtime cost of Stream.parallel().
>
> We still have the separate .parallelStream() method on Collection and in
the static methods in Arrays.
>
> I still really like Collection.parallelStream; it has huge discoverability
advantages, and offers a pretty big return on API surface area -- one more
method, but provides value in a lot of places, since Collection will be a
really common case of a stream source.
>
> Arrays are in a middle ground. We have eight Arrays.stream() methods and
eight Arrays.parallelStream() methods (four types, both whole-array and
slice versions). I'm having a bit of a YAGNI twinge for the
Arrays.parallelStream forms, and could see ditching them. (The
implementations are trivial and small, so that is not an argument to ditch
them -- we should make this decision purely on API considerations.)
>
> If we did this, Collection would have the sole parallelStream method;
everything else would have to go through .parallel(). Which seems fine to
me.
>
I would probably always use always .stream().parallel() idiomatically for
consistency unless parallelStream() told me why I should use it instead. I
say toss all of the parallelStream() methods unless there's an impl
efficiency dependent reason to retain some of them.
Mike
------------------------------
Message: 4
Date: Sat, 20 Apr 2013 18:10:33 -0400
From: Tim Peierls <tim at peierls.net>
Subject: Re: Drop Arrays.parallelStream()?
To: Mike Duigou <mike.duigou at oracle.com>
Cc: lambda-libs-spec-experts at openjdk.java.net
Message-ID:
<CA+F8eeTMpoALe7k59UPSTMHq0Up44020BWjM3rVSbL56uQA19A at mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1
On Sat, Apr 20, 2013 at 6:01 PM, Mike Duigou <mike.duigou at oracle.com> wrote:
> I would probably always use always .stream().parallel() idiomatically for
> consistency unless parallelStream() told me why I should use it instead. I
> say toss all of the parallelStream() methods unless there's an impl
> efficiency dependent reason to retain some of them.
>
Agreed.
I see the discoverability of Collection.parallelStream() as a potential
pedagogical drawback. "Do I use parallelStream() or stream().parallel()?"
For most folks, the expectation and intuition will be sequential, so take
advantage of that: Let people come to c.stream().parallel() slowly and
deliberately, after getting their feet wet with c.stream().
--tim
------------------------------
Message: 5
Date: Sat, 20 Apr 2013 15:16:46 -0700
From: Joe Bowbeer <joe.bowbeer at gmail.com>
Subject: Re: Drop Arrays.parallelStream()?
To: Tim Peierls <tim at peierls.net>
Cc: "lambda-libs-spec-experts at openjdk.java.net"
<lambda-libs-spec-experts at openjdk.java.net>
Message-ID:
<CAHzJPEr7WyWEqADjAu3_qSKA1fezsPZS+A=95UuFRkrDw+p8=A at mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1
I agree with Mike and Tim. I'd remove all the parallelStream() methods now
- and add some or all back later if they ARE needed.
I don't like the inconsistency of having parallelStream available on some
stream factories and not on others.
On Sat, Apr 20, 2013 at 3:10 PM, Tim Peierls <tim at peierls.net> wrote:
> On Sat, Apr 20, 2013 at 6:01 PM, Mike Duigou
<mike.duigou at oracle.com>wrote:
>
>> I would probably always use always .stream().parallel() idiomatically for
>> consistency unless parallelStream() told me why I should use it instead.
I
>> say toss all of the parallelStream() methods unless there's an impl
>> efficiency dependent reason to retain some of them.
>>
>
> Agreed.
>
> I see the discoverability of Collection.parallelStream() as a potential
> pedagogical drawback. "Do I use parallelStream() or stream().parallel()?"
>
> For most folks, the expectation and intuition will be sequential, so take
> advantage of that: Let people come to c.stream().parallel() slowly and
> deliberately, after getting their feet wet with c.stream().
>
> --tim
>
------------------------------
Message: 6
Date: Sat, 20 Apr 2013 18:28:04 -0400
From: Brian Goetz <brian.goetz at oracle.com>
Subject: Re: Drop Arrays.parallelStream()?
To: Tim Peierls <tim at peierls.net>
Cc: lambda-libs-spec-experts at openjdk.java.net
Message-ID: <51731674.4010401 at oracle.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
> For most folks, the expectation and intuition will be sequential, so
> take advantage of that: Let people come to c.stream().parallel() slowly
> and deliberately, after getting their feet wet with c.stream().
I have a slightly different viewpoint about the value of this sequential
intuition -- I view the pervasive "sequential expectation" as one if the
biggest challenges of this entire effort; people are *constantly*
bringing their incorrect sequential bias, which leads them to do stupid
things like using a one-element array as a way to "trick" the "stupid"
compiler into letting them capture a mutable local, or using lambdas as
arguments to map that mutate state that will be used during the
computation (in a non-thread-safe way), and then, when its pointed out
that what they're doing, shrug it off and say "yeah, but I'm not doing
it in parallel."
We've made a lot of design tradeoffs to merge sequential and parallel
streams. The result, I believe, is a clean one and will add to the
library's chances of still being useful in 10+ years, but I don't
particularly like the idea of encouraging people to think this is a
sequential library with some parallel bags nailed on the side.
------------------------------
Message: 7
Date: Sat, 20 Apr 2013 18:37:08 -0400
From: Brian Goetz <brian.goetz at oracle.com>
Subject: Re: Drop Arrays.parallelStream()?
To: Joe Bowbeer <joe.bowbeer at gmail.com>
Cc: "lambda-libs-spec-experts at openjdk.java.net"
<lambda-libs-spec-experts at openjdk.java.net>
Message-ID: <51731894.80107 at oracle.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
For what its worth, the internal tracking title of this project is "Bulk
data-parallel operations on Collections." I'm not willing to relegate
such central functionality to something that is tucked into a remote
corner of the API -- it was *already* a huge (but warranted)
discoverability compromise to have the stream/parallelStream "bun"
methods in the first place! Two buns for this case -- which will be
probably 90% of stream constructions -- would be too much. So, I cannot
see my way to removing Collection.parallelStream. However, I am willing
to ditch the parallel versions of the static stream factory methods,
largely on the basis that the Collection versions will be used 100x as
much as any one of the static factories.
The "inconsistency" of this position doesn't bother me one tiny bit; it
is a pragmatic compromise. (In fact, I'm not even sure its an
inconsistency at all, since they're kind of different beasts -- one is a
static factory, the other is a view onto an existing data structure.)
So I'm willing to meet you 95% of the way there.
On 4/20/2013 6:16 PM, Joe Bowbeer wrote:
> I agree with Mike and Tim. I'd remove all the parallelStream() methods
> now - and add some or all back later if they ARE needed.
>
> I don't like the inconsistency of having parallelStream available on
> some stream factories and not on others.
>
>
>
>
> On Sat, Apr 20, 2013 at 3:10 PM, Tim Peierls <tim at peierls.net
> <mailto:tim at peierls.net>> wrote:
>
> On Sat, Apr 20, 2013 at 6:01 PM, Mike Duigou <mike.duigou at oracle.com
> <mailto:mike.duigou at oracle.com>> wrote:
>
> I would probably always use always .stream().parallel()
> idiomatically for consistency unless parallelStream() told me
> why I should use it instead. I say toss all of the
> parallelStream() methods unless there's an impl efficiency
> dependent reason to retain some of them.
>
>
> Agreed.
>
> I see the discoverability of Collection.parallelStream() as a
> potential pedagogical drawback. "Do I use parallelStream() or
> stream().parallel()?"
>
> For most folks, the expectation and intuition will be sequential, so
> take advantage of that: Let people come to c.stream().parallel()
> slowly and deliberately, after getting their feet wet with c.stream().
>
> --tim
>
>
End of lambda-libs-spec-observers Digest, Vol 8, Issue 30
*********************************************************
More information about the lambda-libs-spec-observers
mailing list