IntStreams and the case of the missing reduce

[Brent Walker]

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