Add Pair class and Itera*s.pairUp()

[GoogleCodeExporter]

A common operation in functional programming languages is zip, which takes
two lists and returns a list of pairs of elements, whose elements are the
elements of the input lists at corresponding position. One problem is that
there are no Pairs (nor any other tuples) in the JDK, but maybe Map.Entry
could be repurposed for this:

public static <A, B> Iterator<Entry<A, B>> zip(final Iterator<A> first,
final Iterator<B> second) {
        return new AbstractIterator<Entry<A,B>>(){
            @Override
            protected Entry<A, B> computeNext() {
                if (!first.hasNext() || !second.hasNext()) {
                    return endOfData();
                }

                return Maps.immutableEntry(first.next(), second.next());
            }
        };
    }

Original issue reported on code.google.com by rafael...@gmail.com on 13 Jul 2009 at 2:58

[GoogleCodeExporter]

I like the idea of zip functions, but I do not think that repurposing Map.Entry 
is a 
good idea for something as simple as a tuple type.  (It also makes sense to 
have 
tuple types of multiple cardinalities, and those should share a naming 
convention, 
which won't be possible with Map.Entry.)

In practice, I find Iterable<T> `zipWith(Function2<R,S,T>, Iterable<R>, 
Iterable<S>)` to be more useful, but that would require a set of Function 
objects 
with higher arity (eg: `Function2<R,S,T>`).  In the zip case, we need tuples, 
and in 
the `zipWith` case we need new Function objects, but they can accomplish 
essentially 
the same thing either way.  My preference is to add increased Arity functions, 
since 
tuples are rarely the final objective (in my experience), and functions of 2+ 
parameters can be useful in other contexts as well (fold/reduce for example)

Original comment by cresw...@gmail.com on 13 Jul 2009 at 4:59

[GoogleCodeExporter]

I agree that having tuple classes would be an improvement over the version with
Map.Entry.

The proposal to add a method that combines a map with a zip is also fine by me, 
but
not in detriment of a simple zip. The issue is not so much that there are cases 
where
tuples aren't the final objective, but that Java's inner class syntactic 
verbosity
makes working with Functions burdensome.

Original comment by rafael...@gmail.com on 14 Jul 2009 at 4:28

[GoogleCodeExporter]

There are already quite a few existing issues regarding functional programming 
facilities. Have a look around. The basic requirement to move forward is a 
tuple 
library (or at least a Pair object). The impression I got is that the google 
collections maintainers are undecided on where to go with regard to functional 
programming. The verbosity is a big problem. Since the maintainers seem to be 
in 
(relatively close) contact with Joshua Bloch, I also suspect they know things 
about 
where the java language/platform is headed that we don't know.

Original comment by jvdne...@gmail.com on 14 Jul 2009 at 10:46

[GoogleCodeExporter]

Internally, Google has a Pair class, along with Iterators and Iterables methods 
that
are similar to zip. We may release them at some point, but not in version 1 of 
Google
Collections.

Original comment by jared.l....@gmail.com on 16 Jul 2009 at 11:07

[GoogleCodeExporter]

No promises that we will get to this, but the request makes sense.

Original comment by kevin...@gmail.com on 12 Aug 2009 at 5:59

• Changed title: *Add Pair class and Iteras.pairUp()**
• Changed state: Accepted
• Added labels: post-1.0

[GoogleCodeExporter]

+1 for Map.Entry compatible Pair. That's a class I've seen reinvented in every
project with enough complexity.

Original comment by earwin@gmail.com on 12 Aug 2009 at 11:49

[GoogleCodeExporter]

Original comment by kevin...@gmail.com on 17 Sep 2009 at 5:45

• Added labels: Milestone-Post1.0
• Removed labels: post-1.0

[GoogleCodeExporter]

Original comment by kevin...@gmail.com on 17 Sep 2009 at 5:57

• Added labels: Type-Enhancement

[GoogleCodeExporter]

This issue has been moved to the Guava project (keeping the same id number). 
Simply replace 'google-collections' with 'guava-libraries' in your address 
bar and it should take you there.

Original comment by kevinb@google.com on 5 Jan 2010 at 11:09

• Changed state: Moved