[guava] Is there a concrete Pair implementation?

[Maarten Billemont]

Quoting from <Idea Graveyard - ideas we have rejected>:
- Tuples for n > 2
..
- create a map from an Iterable<Pair>, ...

From this context I was lead to believe a Pair class exists in Guava.
However, I can't find any such implementation.

Is providing a concrete implementation of Map.Entry in
com.google.common.collect not a good idea?

--
guava-...@googlegroups.com.
http://groups.google.com/group/guava-discuss?hl=en
unsubscribe: guava-discus...@googlegroups.com

This list is for discussion; for help, post to Stack Overflow instead:
http://stackoverflow.com/questions/ask
Use the tag "guava".

[Torbjorn Gannholm]

On Fri, May 7, 2010 at 10:33 AM, Maarten Billemont <lhu...@gmail.com> wrote:

Quoting from <Idea Graveyard - ideas we have rejected>:
 - Tuples for n > 2
..
 - create a map from an Iterable<Pair>, ...

From this context I was lead to believe a Pair class exists in Guava.
However, I can't find any such implementation.

 

Pair is not a good idea. Pair is too easy to use, but makes your code less readable because you lose the semantic information as to why the two values belong together.
Better to create classes like "PhonebookEntry(name, number)".

Is providing a concrete implementation of Map.Entry in
com.google.common.collect not a good idea?

Map.Entry is slightly different in that it indicates that one value is a key used to access the other from a Map. But if it starts moving too far away from the map itself, you again lose the knowledge of why they belong together.

So probably not a good idea, either.

/tobe
 

--
guava-...@googlegroups.com.
http://groups.google.com/group/guava-discuss?hl=en
unsubscribe: guava-discus...@googlegroups.com

This list is for discussion; for help, post to Stack Overflow instead:
http://stackoverflow.com/questions/ask
Use the tag "guava".

[Lhunath (Maarten B.)]

On 07 May 2010, at 10:44, Torbjorn Gannholm wrote:
> Pair is not a good idea. Pair is too easy to use, but makes your code less readable because you lose the semantic information as to why the two values belong together.

Very valid point. Thanks.

[Rafael de F. Ferreira]

On Fri, May 7, 2010 at 5:44 AM, Torbjorn Gannholm <to...@google.com> wrote:
>
> Pair is not a good idea. Pair is too easy to use, but makes your code less
> readable because you lose the semantic information as to why the two values
> belong together.
> Better to create classes like "PhonebookEntry(name, number)".

I do get the point (previously discussed in an OpenJDK mailing list)
that including a Pair class can quickly lead to abuse. But sometimes
it can be very useful in intermediate calculations, for instance using
with the zip method (issue 203).

--
Rafael de F. Ferreira.
http://www.rafaelferreira.net/

[Kevin Bourrillion]

Regardless, a large number of us maintaining the libraries hold that it does more harm than good.  Code that uses Pair that is rewritten to not use Pair almost always ends up better in one way or another.

But the reason for the odd wording on the graveyard page is that Pair is not among the set of things definitively rejected for Guava, unlike those other things which (for some definition of definitive) have been.  Though, from recent discussions I'd say it's pretty darn close.

--
Kevin Bourrillion @ Google
internal:  http://goto/javalibraries
external: http://guava-libraries.googlecode.com

[Jed Wesley-Smith]

Q: What makes Java so manly?

A: It forces every programmer to grow a Pair.

http://james-iry.blogspot.com/2010/05/anatomy-of-annoyance.html

[ms...@google.com]

The lack of a Pair in Java leads people to use maps where pair would be perfectly valid (and more efficient) solution. It's probably not such a bad idea, given that languages like Rust are borrowing the concept of Tuples from Haskell. You have to realize that sometimes you need a pair just to pass values between two methods, and creating a new class for this use case is extremely onerous.

[Luke Sandberg]

Use @AutoValue https://github.com/google/auto/tree/master/value it makes writing nice value types trivial

--
--
guava-...@googlegroups.com
Project site: http://guava-libraries.googlecode.com
This group: http://groups.google.com/group/guava-discuss
 
This list is for general discussion.
To report an issue: http://code.google.com/p/guava-libraries/issues/entry
To get help: http://stackoverflow.com/questions/ask?tags=guava
---
You received this message because you are subscribed to the Google Groups "guava-discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email to guava-discus...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/guava-discuss/12fafa58-0a1c-4441-83f7-7326869e483c%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Louis Wasserman]

The entry in the Idea Graveyard is "tuples for n >= 2", not for n > 2.

Louis Wasserman
wasserm...@gmail.com
http://profiles.google.com/wasserman.louis

On Fri, Sep 12, 2014 at 3:40 PM, <ms...@google.com> wrote:

--

[Daniel Rothmaler]

Actually there is a Pair Implementation in guava; the ImmutableEntry… 

It is an internal class, but you can still use it, using Maps.immutabelEntry (see http://docs.guava-libraries.googlecode.com/git/javadoc/com/google/common/collect/Maps.html#immutableEntry(K,%20V) ).

Best regards, 

Daniel

To view this discussion on the web visit https://groups.google.com/d/msgid/guava-discuss/CA%2BtXMXOt%3DKeFt9NN82b2%2BfaP4nmR21OmAEq%3DMfijG4QyKqXNow%40mail.gmail.com.