Concat and zip

[Brian Goetz]

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

On 5/1/2013 5:05 PM, Joe Bowbeer wrote:
> I've used zip in Python and Scala, so I'm pretty sure I'll be looking
> for it in Java8.
>
>
> On Wed, May 1, 2013 at 1:51 PM, Raab, Donald [Tech] <Donald.Raab at gs.com
> <mailto:Donald.Raab at gs.com>> wrote:
>
>     I'm polling to see how many users of GS Collections have used zip
>     internally.  We have it on our object API, not on our primitive API.
>       I'll let you know the response I get in the next day or so.
>
>      > -----Original Message-----
>      > From: lambda-libs-spec-experts-bounces at openjdk.java.net
>     <mailto:lambda-libs-spec-experts-bounces at openjdk.java.net>
>     [mailto:lambda- <mailto:lambda->
>      > libs-spec-experts-bounces at openjdk.java.net
>     <mailto:libs-spec-experts-bounces at openjdk.java.net>] On Behalf Of
>     Brian Goetz
>      > Sent: Wednesday, May 01, 2013 4:43 PM
>      > To: Tim Peierls
>      > Cc: lambda-libs-spec-experts at openjdk.java.net
>     <mailto:lambda-libs-spec-experts at openjdk.java.net>
>      > Subject: Re: Concat and zip
>      >
>      > Yes, a key aspect of this YAGNI suggestion is that this is one of the
>      > things people CAN do for themselves, possibly with an example.  And,
>      > because there are multiple ways to do zip (pad out shorter stream to
>      > size of longer stream, stop at end of shorter stream, throw if
>     streams
>      > are not of equal length) people may well want to roll their own.
>      >
>      > On 5/1/2013 4:25 PM, Tim Peierls wrote:
>      > > On Wed, May 1, 2013 at 4:03 PM, Joe Bowbeer
>     <joe.bowbeer at gmail.com <mailto:joe.bowbeer at gmail.com>
>      > > <mailto:joe.bowbeer at gmail.com <mailto:joe.bowbeer at gmail.com>>>
>     wrote:
>      > >
>      > >     In defense of zip: I think it is fairly important.  Ease of
>      > >     expression (and productivity) are still the most valuable
>      > benefits
>      > >     of new features, and zip is important for a class of problems.
>      > zip
>      > >     exists in Python, Scala, and Groovy (as "transpose" method), to
>      > name
>      > >     a few.
>      > >
>      > >     I would keep zip without Int/Long/Double versions.  This also
>      > avoids
>      > >     all the varieties of mixed primitive/Object pairings in zipped
>      > streams.
>      > >
>      > >
>      > > That sounds reasonable. I was going to say make the ref/ref version
>      > an
>      > > example in javadoc and then people can roll their own primitive/ref
>      > > versions, but maybe that's asking too much.
>      > >
>      > > --tim
>
>