Drop Arrays.parallelStream()?

[Joe Bowbeer]

Brian, What do you mean by the following?

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 [...] would be too much.


Are you referring to the fact the there is no ParallelStream type?

Note that the common point that Mike, Tim, and I raised is consistency.
 Your proposal to remove methods is creating the inconsistency, so I don't
understand the comment that you're meeting us 95% of the way there...

That said, I think I can view Collection and Arrays as two different things
that have little bearing on each other (if I squint).

Still, why, if you're so interested in advertising the parallel features,
do you *want* to remove these methods from Arrays?

Finally, Brian writes:

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


Then again, users like consistency...

Joe


On Sat, Apr 20, 2013 at 3:37 PM, Brian Goetz <brian.goetz at oracle.com> wrote:

> 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
>>
>>
>>