java.util.Pair

[Kevin Bourrillion]

On Wed, Mar 31, 2010 at 8:36 AM, Bob Lee <crazybob at crazybob.org> wrote:

Please don't add Pair. It should never be used in APIs. Adding it to
> java.util will enable and even encourage its use in APIs. The damage done to
> future Java APIs will be far worse than a few duplicate copies of Pair (I
> don't even see that many). I think we'll have a hard time finding use cases
> to back up this addition.
>

FYI, here are some examples of types you can look forward to seeing in Java
code near you when you have a Pair class available:

 Pair<List<String>,List<Pair<String,List<Boolean>>>>

 Map<Double,List<Pair<QueryTuple,Map<StatType,Number>>>>

 Map<Locale,Map<String,Pair<DisplayTimeScheme,Pair<String,String>>>>

 FJ.EmitFn<Pair<Long, List<Pair<String, List<Pair<Integer, Integer>>>>>>

 Processor<Pair<List<DiffItem<T>>,Pair<List<T>,List<T>>>,List<DiffItem<T>>>

 DoFn<Pair<String,Collection<Pair<String,Pair<Double,String>>>>,Pair<String,List<Pair<String,Pair<Double,String>>>>>

These are all real examples found in real, live production code (simplified
a little).  There were only a scant few examples of this... caliber... that
did not involve Pair.

The problem is that classes like Pair simply go that much further to indulge
the desire to never have to create any actual types of our own.  When we're
forced to create our own types, we begin to model our data more
appropriately, which I believe leads us to create good abstractions at
broader levels of granularity as well.


-- 
Kevin Bourrillion @ Google
internal:  http://goto/javalibraries
external: http://guava-libraries.googlecode.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/core-libs-dev/attachments/20100331/4935c245/attachment.html>