Fwd: Loose end: zip

[Paul Sandoz]

Hi,

If anyone has experimented with Streams.zip can you provide some feedback? see email below for context.

Paul.

Begin forwarded message:

> From: Brian Goetz <brian.goetz at oracle.com>
> Subject: Loose end: zip
> Date: June 6, 2013 9:49:05 PM GMT+02:00
> 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>
> Reply-To: lambda-libs-spec-observers at openjdk.java.net
> 
> Still feeling kind of YAGNI on zip, for the reasons cited in the message below, plus:
> - No primitive versions (would require new SAMs)
> - Hard to parallelize
> - Multiple ways to deal with streams of different length; we pick one
> 
> Might this be something best provided by some other library than the JDK?  Or as a code example somewhere people can crib from to roll their own?
> 
> On 5/1/2013 5:10 PM, Brian Goetz wrote:
>> Right, but the question is, how badly can we implement it and have it
>> not be worse than nothing?  And, with the current performance
>> characteristics (new object per element), are we below that threshold?
>> 
>> My problem is the same as with flatMap -- these are idioms from other
>> languages that *translate poorly* to Java because of the lack of tuples
>> and other structural types.  (The flatMap we got left with -- which I
>> reluctantly supported as the lesser of evils -- is, coincidentally, the
>> only other stream operation that has allocation-per-element.)  At what
>> level of translation-fidelity loss do we say "yeah, it works great in
>> that other environment, but too much is lost in translation"?
>> 
>> I don't doubt the utility of zip, or the fact that Joe-alikes will want
>> it, and would be bummed to not find it.  My question is whether the
>> crappy zip we can have is better than no zip.  (Where better doesn't
>> just mean "better than nothing", but carries its weight.)