Drop Arrays.parallelStream()?

[Joe Bowbeer]

Thanks for clarifying.

Most of your justifications seem to be a matter of taste, so there is no
use arguing. (Taste, like foolishness, defies argument.)

Alas, after cleansing my mind of "foolish hobgoblins" and other distracting
remarks, I think your proposal is an improvement, even without squinting.
On Apr 20, 2013 4:29 PM, "Brian Goetz" <brian.goetz at oracle.com> wrote:

> 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?
>>
>
> No, that's a big plus -- one Stream to rule them all!
>
> The negative was having to have the
>
>   .stream()
> and
>   .parallelStream()
>
> methods at all.  We originally really liked the idea of
>
>   collection.filter(..)...
>             ^ no view method!
>
> but for various reasons reluctantly concluded it was untenable.  But that
> still doesn't mean we like having the new functionality be so far removed
> from Collection.  And if one layer removed is suboptimal, two is worse.
>
>  Note that the common point that Mike, Tim, and I raised is consistency.
>>   Your proposal to remove methods is creating the inconsistency, so I
>>
>
> Not really.  We were already inconsistent; they were present for
> Collection and for Array factories but not for range factories, generator
> factories, etc.  You could argue the new proposed state is more consistent
> (all the view methods have a parallel counterpart; all the static factories
> don't) but that's not what I consider its primary benefit.
>
>  don't understand the comment that you're meeting us 95% of the way
>> there...
>>
>
> Removing all but one of the parallelStream methods.
>
>  Still, why, if you're so interested in advertising the parallel
>> features, do you *want* to remove these methods from Arrays?
>>
>
> Simply: return on API surface area.  The return for having it the one
> extra method on Collection is large; the return for having 100 extra
> methods for 100 infrequently-used factory methods is small (even in the
> aggregate).  Arrays.parallelStream() was eight more methods -- four types x
> two forms.  (Others here have argued that "too many forms of the same
> method is a smell"; also there have been plenty of calls for a round of
> YAGNIism.)
>
>      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...
>>
>
> I'm not saying consistency is unimportant.  But in my experience,
> "consistency" can be used to justify nearly any position -- one can always
> find a precedent in a complex system to be "consistent" with.  So I want
> more than mere consistency.  (Not to mention many consistencies are of the
> "foolish hobgoblin" variety.)
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.openjdk.java.net/pipermail/lambda-libs-spec-experts/attachments/20130420/c4a631c5/attachment.html