Loose end: zip

[Brian Goetz]

Yeah, I'm not surprised.  Zip is an idiom that is built on the 
assumption of tuples.

"To Pair or Not To Pair" is well covered ground; every time it has come 
up, the consensus has been "more harm than good."  For example:

 
http://mail.openjdk.java.net/pipermail/core-libs-dev/2010-March/003994.html
 
http://mail.openjdk.java.net/pipermail/core-libs-dev/2010-March/003997.html



On 6/9/2013 12:40 AM, Joe Bowbeer wrote:
> I have not used this zip, actually, and I just tried to use it and I was
> not pleased.
>
> When I use zip, I'm usually pairing keys to items.  Usually the keys are
> ints and the items are some app-specific object, or maybe just a string:
>
> zipped = zip(ints(), collection.stream());
>
> *This* version of zip requires me to supply a third "zipper" argument,
> which means I also have to make up a type for the pairs.
>
> What I really want is a zip that returns Stream<Pair<A,B>> so I don't
> have to deal with the pairing:
>
> <A,B> Stream<Pair<A,B>> zip(Stream<? extends A> a, Stream<? extends B> b)
>
> --Joe
>
>
> On Thu, Jun 6, 2013 at 4:53 PM, Brian Goetz <brian.goetz at oracle.com
> <mailto:brian.goetz at oracle.com>> wrote:
>
>     Has anyone on the EG experimented with *this* version of zip?  Do
>     you have experience to report?
>
>
>     On 6/6/2013 6:58 PM, Joe Bowbeer wrote:
>
>         I don't think I have anything to add to what I already said: zip
>         is an
>         expressive, useful tool.
>
>         Java programmers effectively use maps of maps, and maps of
>         lists, and
>         lists of maps, and all kinds of inefficient things.
>
>         Originally, Java's biggest advantage was its increased productivity.
>            That one advantage can make up for lots of little
>         disappointments.
>
>         I definitely don't want to have to search for a zip snippet
>         somewhere
>         (e.g., in Fugue?).  A basic tool like zip is not something I
>         would look
>         for in an extension library.
>
>         Regarding the no-primitive versions, I think the consensus was
>         to live
>         with that.
>
>
>         On Thu, Jun 6, 2013 at 12:49 PM, Brian Goetz
>         <brian.goetz at oracle.com <mailto:brian.goetz at oracle.com>
>         <mailto:brian.goetz at oracle.com
>         <mailto:brian.goetz at oracle.com>__>> wrote:
>
>              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.)
>
>
>