Concat and zip

[Raab, Donald [Tech]]

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