New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add Pair class and Itera*s.pairUp() #203
Comments
Original comment posted by creswick on 2009-07-13 at 04:59 PM I like the idea of zip functions, but I do not think that repurposing Map.Entry is a In practice, I find Iterable<T> |
Original comment posted by rafaeldff on 2009-07-14 at 04:28 AM I agree that having tuple classes would be an improvement over the version with The proposal to add a method that combines a map with a zip is also fine by me, but |
Original comment posted by jvdneste on 2009-07-14 at 10:46 AM There are already quite a few existing issues regarding functional programming |
Original comment posted by jared.l.levy on 2009-07-16 at 11:07 PM Internally, Google has a Pair class, along with Iterators and Iterables methods that |
Original comment posted by kevinb9n on 2009-08-12 at 05:59 PM No promises that we will get to this, but the request makes sense. Status: |
Original comment posted by earwin on 2009-08-12 at 11:49 PM +1 for Map.Entry compatible Pair. That's a class I've seen reinvented in every |
Original comment posted by kevinb9n on 2009-09-17 at 05:45 PM (No comment entered for this change.) Labels: - |
Original comment posted by kevinb9n on 2009-09-17 at 05:57 PM (No comment entered for this change.) Labels: |
Original comment posted by kevinb@google.com on 2010-07-30 at 03:53 AM (No comment entered for this change.) Labels: - |
Original comment posted by morten.hattesen on 2011-03-19 at 05:17 PM I'd like to see the Pair class make it into Guava soon. |
Original comment posted by amertum on 2011-03-22 at 08:50 AM I don't really like the idea of tuple class. At first it looks great but when you have a lot of Pair, Triple... and so on, you have lost the meaning of the tuple name. I saw things like a value and a currency goes into a Pair or worst a Map.Entry while it is an Amount. The cost to write an Amount class (or whatever that fits better) is really really better IMHO. |
Original comment posted by eric.jain on 2011-03-22 at 04:56 PM If Java had something like Scala's case classes that generate the equals/hashCode/toString methods and can be defined in one line, I'd agree that a Pair class doesn't add much value. |
Original comment posted by kandpwelker on 2011-07-13 at 05:07 AM I have been playing with the design of Tuples, and what has been convenient is to have a Tuples class with the different predefined arities implemented as static classes within the Tuples class so that you can statically import the whole thing to get all of your arity types and static factory methods at the same time. For notational brevity, the types could be implemented with names such as "_1" (for arity 1), "_2" (for arity 2, etc.) That kind of naming may seem like anathema to some, but without the static import it would read more explicitly as Tuples._1, Tuples._2, etc. And the many overloaded static factory methods would share the same name which would serve to look almost like an operator: "_" So to create a new pair or triplet with static imports, it would simply look like: |
Original comment posted by j...@nwsnet.de on 2011-07-13 at 10:45 AM I just like to share my two implementations of "zip": one cutting off the longer input iterable, the other one padding the shorter input iterable. They are named after Scala's, from which I also learned about the idea of providing pad values instead of using Regarding a pair/tuple class, I currently have no further ideas except for accepting a function argument that would be called for every pair to be created, allowing instanciation of a custom pair class for the current domain and use case. That is a lot of overhead (at least in reading and writing the code), though. |
Original comment posted by kevinb@google.com on 2011-07-13 at 06:18 PM (No comment entered for this change.) Status: |
Original comment posted by fry@google.com on 2011-12-10 at 03:39 PM (No comment entered for this change.) Labels: |
Original comment posted by kevinb@google.com on 2012-02-16 at 06:47 PM We've discussed this extensively and we have decided that we will not be releasing a Pair class in Guava. Sorry! Status: |
Original comment posted by bolinfest on 2012-11-12 at 05:51 PM FYI, the Idea Graveyard (http://code.google.com/p/guava-libraries/wiki/IdeaGraveyard) has a more detailed explanation of why there is no Pair class in the "Tuples for n >= 2" section. |
Original comment posted by morten.hattesen on 2012-11-12 at 05:59 PM I wonder what the rationale for rejecting a tuple with n=2 (i.e. a Pair) is, though. Guess we'll never know. |
Original comment posted by lowasser@google.com on 2012-11-12 at 06:16 PM Eh? The rationale's right there, in the same place. |
Original comment posted by morten.hattesen on 2012-11-12 at 06:34 PM OK, my bad. I still wonder, though, what makes so may projects roll their own Pair I'll leave this issue to the peace of the Ideas Graveyard. |
Original comment posted by alex.panchenko on 2012-11-13 at 02:34 AM I agree, that it could be easily abused by using it instead of Point or whatever classes. However, there is nothing bad when using it locally as Map key for example. That's the motivation of having it in many projects, as quite often you are getting tired of defining *Key classes multiple times. |
Original comment posted by jbellis on 2012-11-13 at 02:38 AM Also, method return values. Sometimes the values you want to return are unrelated except by the fact that they are computed together. |
Original comment posted by wasserman.louis on 2012-11-13 at 04:24 AM We're quite firm in our opinion, but to give a bit more detail -- a) If you're using a pair as a Map key, you'd probably be better off using a Table, not a Map. |
Original comment posted by Maaartinus on 2012-11-13 at 05:40 AM I sort of agree with your reasons against Pair, but to give some (sort of real-world) counter examples: a) I'm caching a binary function and there's nothing like TableCache. Even if there was such a thing, it would probably consume more time and space. Anyway, using getFirst/Second is ugly, but not as ugly as writing a one-shot class. |
Original issue created by rafaeldff on 2009-07-13 at 02:58 AM
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();
}
The text was updated successfully, but these errors were encountered: