<div dir="ltr">Those arguments against Pair are pretty old, and sound a lot like the arguments against fleshing-out Optional (reflecting the current state of Guava).<div><br></div><div><div style>*Not* requiring functional programmers to create their own types at every opportunity facilitates fluent programming.<br>
</div></div><div style><br></div><div style><div>Pair already exists in Java in the form of Map.Entry.  Having Map.Entry extend Pair would be my approach, btw.</div><div><br></div><div style>Joe</div></div></div><div class="gmail_extra">
<br><br><div class="gmail_quote">On Sat, Jun 8, 2013 at 11:00 PM, Brian Goetz <span dir="ltr">&lt;<a href="mailto:brian.goetz@oracle.com" target="_blank">brian.goetz@oracle.com</a>&gt;</span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Yeah, I&#39;m not surprised.  Zip is an idiom that is built on the assumption of tuples.<br>
<br>
&quot;To Pair or Not To Pair&quot; is well covered ground; every time it has come up, the consensus has been &quot;more harm than good.&quot;  For example:<br>
<br>
<br>
<a href="http://mail.openjdk.java.net/pipermail/core-libs-dev/2010-March/003994.html" target="_blank">http://mail.openjdk.java.net/<u></u>pipermail/core-libs-dev/2010-<u></u>March/003994.html</a><br>
<br>
<a href="http://mail.openjdk.java.net/pipermail/core-libs-dev/2010-March/003997.html" target="_blank">http://mail.openjdk.java.net/<u></u>pipermail/core-libs-dev/2010-<u></u>March/003997.html</a><div class="im"><br>
<br>
<br>
<br>
On 6/9/2013 12:40 AM, Joe Bowbeer wrote:<br>
</div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="im">
I have not used this zip, actually, and I just tried to use it and I was<br>
not pleased.<br>
<br>
When I use zip, I&#39;m usually pairing keys to items.  Usually the keys are<br>
ints and the items are some app-specific object, or maybe just a string:<br>
<br>
zipped = zip(ints(), collection.stream());<br>
<br>
*This* version of zip requires me to supply a third &quot;zipper&quot; argument,<br>
which means I also have to make up a type for the pairs.<br>
<br>
What I really want is a zip that returns Stream&lt;Pair&lt;A,B&gt;&gt; so I don&#39;t<br>
have to deal with the pairing:<br>
<br>
&lt;A,B&gt; Stream&lt;Pair&lt;A,B&gt;&gt; zip(Stream&lt;? extends A&gt; a, Stream&lt;? extends B&gt; b)<br>
<br>
--Joe<br>
<br>
<br>
On Thu, Jun 6, 2013 at 4:53 PM, Brian Goetz &lt;<a href="mailto:brian.goetz@oracle.com" target="_blank">brian.goetz@oracle.com</a><br></div><div class="im">
&lt;mailto:<a href="mailto:brian.goetz@oracle.com" target="_blank">brian.goetz@oracle.com</a><u></u>&gt;&gt; wrote:<br>
<br>
    Has anyone on the EG experimented with *this* version of zip?  Do<br>
    you have experience to report?<br>
<br>
<br>
    On 6/6/2013 6:58 PM, Joe Bowbeer wrote:<br>
<br>
        I don&#39;t think I have anything to add to what I already said: zip<br>
        is an<br>
        expressive, useful tool.<br>
<br>
        Java programmers effectively use maps of maps, and maps of<br>
        lists, and<br>
        lists of maps, and all kinds of inefficient things.<br>
<br>
        Originally, Java&#39;s biggest advantage was its increased productivity.<br>
           That one advantage can make up for lots of little<br>
        disappointments.<br>
<br>
        I definitely don&#39;t want to have to search for a zip snippet<br>
        somewhere<br>
        (e.g., in Fugue?).  A basic tool like zip is not something I<br>
        would look<br>
        for in an extension library.<br>
<br>
        Regarding the no-primitive versions, I think the consensus was<br>
        to live<br>
        with that.<br>
<br>
<br>
        On Thu, Jun 6, 2013 at 12:49 PM, Brian Goetz<br>
        &lt;<a href="mailto:brian.goetz@oracle.com" target="_blank">brian.goetz@oracle.com</a> &lt;mailto:<a href="mailto:brian.goetz@oracle.com" target="_blank">brian.goetz@oracle.com</a><u></u>&gt;<br></div>
        &lt;mailto:<a href="mailto:brian.goetz@oracle.com" target="_blank">brian.goetz@oracle.com</a><div><div class="h5"><br>
        &lt;mailto:<a href="mailto:brian.goetz@oracle.com" target="_blank">brian.goetz@oracle.com</a><u></u>&gt;__&gt;&gt; wrote:<br>
<br>
             Still feeling kind of YAGNI on zip, for the reasons cited<br>
        in the<br>
             message below, plus:<br>
               - No primitive versions (would require new SAMs)<br>
               - Hard to parallelize<br>
               - Multiple ways to deal with streams of different length;<br>
        we pick one<br>
<br>
             Might this be something best provided by some other library<br>
        than the<br>
             JDK?  Or as a code example somewhere people can crib from<br>
        to roll<br>
             their own?<br>
<br>
             On 5/1/2013 5:10 PM, Brian Goetz wrote:<br>
<br>
                 Right, but the question is, how badly can we implement<br>
        it and<br>
                 have it<br>
                 not be worse than nothing?  And, with the current<br>
        performance<br>
                 characteristics (new object per element), are we below that<br>
                 threshold?<br>
<br>
                 My problem is the same as with flatMap -- these are<br>
        idioms from<br>
                 other<br>
                 languages that *translate poorly* to Java because of<br>
        the lack of<br>
                 tuples<br>
                 and other structural types.  (The flatMap we got left<br>
        with --<br>
                 which I<br>
                 reluctantly supported as the lesser of evils -- is,<br>
                 coincidentally, the<br>
                 only other stream operation that has<br>
        allocation-per-element.)<br>
                   At what<br>
                 level of translation-fidelity loss do we say &quot;yeah, it<br>
        works<br>
                 great in<br>
                 that other environment, but too much is lost in<br>
        translation&quot;?<br>
<br>
                 I don&#39;t doubt the utility of zip, or the fact that<br>
        Joe-alikes<br>
                 will want<br>
                 it, and would be bummed to not find it.  My question is<br>
        whether the<br>
                 crappy zip we can have is better than no zip.  (Where<br>
        better doesn&#39;t<br>
                 just mean &quot;better than nothing&quot;, but carries its weight.)<br>
<br>
<br>
<br>
</div></div></blockquote>
</blockquote></div><br></div>