IntStreams and the case of the missing reduce

[Brian Goetz]

As Richard pointed out, these were all delicate compromises, and I'm 
sure we didn't make every decision perfectly.  You can argue with the 
wisdom of any particular compromise, but what you can't do is say "3 
types is all we need to add", because you're forgetting the infinite 
number of *other* people who each have a pet feature that got left out. 
  We'd have to take the union of all the pet features of all the other 
people to get to an "all we'd need to do" solution.

In other words, we're at a compromise now, and where you're proposing 
would simply be a *different* compromise.  Which is fine, you can argue 
the merits of one compromise vs another, and the EG definitely did so at 
length, but don't fool yourself that there's a "right" answer and a 
"wrong" answer.



On 1/7/2014 9:20 AM, Brent Walker wrote:
> As I said in my original email the primitive to primitive we could in my
> opinion live without.  It is in the mapping from primitives to the infinity
> of user defined types (the objects domain) that hurts and breaks the
> "abstraction" that all streams (primitive and Stream<T>) are created equal.
>   So in total yes 3 types is all we needed to add.  And we would get the
> most general version of reduce for the primitive streams -- which by virtue
> of being the most general can implement the other two reduce() methods that
> did make it in.
>
> Brent
>
>
>
> On Tue, Jan 7, 2014 at 2:49 PM, Richard Warburton <
> richard.warburton at gmail.com> wrote:
>
>> Hi,
>>
>> Yes it would.  And because of one extra type we lost the symmetry between
>>> the primitive and object streams, and lost the most useful reduce method
>>> for raw streams.  I would call that the poorer choice.  The existence of
>>> the distinction between primitives and objects in Java is annoying enough
>>> as it is -- what's the point of exasperating it by building interfaces
>>> with
>>> asymmetrys and missing methods for the primitives vs objects.
>>>
>>
>> I think the thing you need to consider is whenever you say "one more
>> functional interface" for primitives its really 3 since you need to cover
>> int/long/double. And if you need to specialise by two arguments which might
>> be different (eg: zip) then its 9 interfaces.
>>
>> If you look at the API as a whole there are compromises, especially around
>> primitives. The real solution to the primitive problems is a unified type
>> system rather than adding loads more functional interfaces. Hopefully this
>> will be a focus of development in Java 9.
>>
>> regards,
>>
>>    Richard Warburton
>>
>>    http://insightfullogic.com
>>    @RichardWarburto <http://twitter.com/richardwarburto>
>>
>