Do we want a java.util.Pair ?



Do we want a java.util.Pair ?

An interesting discussion popped up this week about whether it would be useful to add a java.util.Pair in JDK 7. This has been requested many times in the past and I know I've heard some talk about it on the Java Posse as well. Pair is of course a special case for two elements and suggests possibly a Triple or Tuple as well, although Pair seems vastly more common than either of those.

I believe by far the most common use case for a Pair is to return multiple values from a single function. Dick Wall made a case for Pair in his Funky Java talk at Devoxx. I certainly found a number of Pair implementors and fans on Twitter. Joe Darcy seemed to think the large number of Pairs in the wild were an indication that having a single version in the JDK might be better than many different implementations and he submitted a strawman version.

It was rightly pointed out that both mutable (AbstractMap.SimpleEntry<K,V>) and immutable (AbstractMap.SimpleImmutableEntry<K,V>) implementations exist in java.util now although they are obviously a bit buried in their current incarnation and probably even less usefully named than Pair.

I believe the major dissent focuses on how Pair is a poor class name and has poor method names. "Pair" does not name the thing you are returning in any useful way other than telling you it's "two things". The methods of Pair are usually also generic as in "getA" or "getFirst". If there is a real meaning behind putting those values together, then there is probably also a better conceptual name to use instead. If the two values really aren't related in any useful way, then the code is probably poorly factored to start with due to a bad separation of concerns.

Bob Lee made a strong plea against Pair (with support from Mark Reinhold) as it would encourage the proliferation of bad code. Kevin Bourrillion and Josh Bloch were also arguing against Pair for JDK 7 but thought that a more general solution of n-arg value types might be a useful thing to attack in a future JDK.

I must admit that I have created and used a Pair at least once in the past, but it made me feel dirty and I eventually refactored it away. Interestingly, I've seen the same issue even in Clojure. When I've written code that returns a seq that I must pick apart with first, second, etc, it feels equally dirty. Working with collections of homogenous elements is great but as soon as positional behavior matters, I feel uncomfortable. In Clojure, it can still be ok, but only if the scope happens within a single function and even then I prefer to use destructuring rather than first or second.


Read full article from Do we want a java.util.Pair ?


No comments:

Post a Comment

Labels

Algorithm (219) Lucene (130) LeetCode (97) Database (36) Data Structure (33) text mining (28) Solr (27) java (27) Mathematical Algorithm (26) Difficult Algorithm (25) Logic Thinking (23) Puzzles (23) Bit Algorithms (22) Math (21) List (20) Dynamic Programming (19) Linux (19) Tree (18) Machine Learning (15) EPI (11) Queue (11) Smart Algorithm (11) Operating System (9) Java Basic (8) Recursive Algorithm (8) Stack (8) Eclipse (7) Scala (7) Tika (7) J2EE (6) Monitoring (6) Trie (6) Concurrency (5) Geometry Algorithm (5) Greedy Algorithm (5) Mahout (5) MySQL (5) xpost (5) C (4) Interview (4) Vi (4) regular expression (4) to-do (4) C++ (3) Chrome (3) Divide and Conquer (3) Graph Algorithm (3) Permutation (3) Powershell (3) Random (3) Segment Tree (3) UIMA (3) Union-Find (3) Video (3) Virtualization (3) Windows (3) XML (3) Advanced Data Structure (2) Android (2) Bash (2) Classic Algorithm (2) Debugging (2) Design Pattern (2) Google (2) Hadoop (2) Java Collections (2) Markov Chains (2) Probabilities (2) Shell (2) Site (2) Web Development (2) Workplace (2) angularjs (2) .Net (1) Amazon Interview (1) Android Studio (1) Array (1) Boilerpipe (1) Book Notes (1) ChromeOS (1) Chromebook (1) Codility (1) Desgin (1) Design (1) Divide and Conqure (1) GAE (1) Google Interview (1) Great Stuff (1) Hash (1) High Tech Companies (1) Improving (1) LifeTips (1) Maven (1) Network (1) Performance (1) Programming (1) Resources (1) Sampling (1) Sed (1) Smart Thinking (1) Sort (1) Spark (1) Stanford NLP (1) System Design (1) Trove (1) VIP (1) tools (1)

Popular Posts