Tabulators -- a catalog (original) (raw)

Brian Goetz brian.goetz at oracle.com
Fri Dec 28 07:38:33 PST 2012

See this thread: http://mail.openjdk.java.net/pipermail/core-libs-dev/2010-March/003973.html

Some excerpts:

Kevin: Pair is only a partial, flawed solution to a special case (n=2) of a very significant problem: the disproportionate complexity of creating value types in Java. I support addressing the underlying problem in Java 8, and not littering the API with dead-end solutions like Pair.

CrazyBob: 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.

Kevin: 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,List<Pair<String,List>>>

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>,Pair<List,List>>,List<DiffItem>>

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.

On 12/28/2012 10:30 AM, Sam Pullara wrote:

Remind me against what exactly is the issue with having a Pair class? Returning an Object[] here is pretty awful isn't it?

Sam On Dec 28, 2012, at 10:28 AM, Brian Goetz <brian.goetz at oracle.com> wrote:

So the thing to do here is return Object[] instead of T[] / D[]. Sad, but not terrible. Not important enough to have the user pass in a factory. For want of a Pair...

On 12/28/2012 9:39 AM, Remi Forax wrote: On 12/28/2012 03:23 AM, Brian Goetz wrote: Here's a catalog of the currently implemented Tabulators.

[...]

3. Partition. Partitions a stream according to a predicate. Results always are a two-element array of something. Five forms:

// Basic Tabulator<T, Collection[]> partition(Predicate predicate) // Explicit factory <T, C extends Collection> Tabulator<T, C[]> partition(Predicate predicate, Supplier rowFactory) // Partitioned mutable reduce <T, D> Tabulator<T, D[]> partition(Predicate predicate, MutableReducer<T,D> downstream) // Partitioned functional reduce Tabulator<T, T[]> partition(Predicate predicate, T zero, BinaryOperator reducer) // Partitioned functional map-reduce Tabulator<T, T[]> partition(Predicate predicate, T zero, Function<T, U> mapper, BinaryOperator reducer) You can't create an array of T (C, D) safely, so casting an array of Object to an array of T is maybe acceptable if you control all the access to that array like in collections, but here you export it. Rémi

More information about the lambda-libs-spec-experts mailing list