Concat and zip
brian.goetz at oracle.com
Wed May 1 14:10:33 PDT 2013
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
> > 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>>>
> > >
> > > 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
More information about the lambda-libs-spec-observers