On Wed, Mar 31, 2010 at 8:36 AM, Bob Lee <crazy...@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
