Tabulators -- a catalog

[Brian Goetz]

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


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
>>>>     <T> Tabulator<T, Collection<T>[]>
>>>>     partition(Predicate<T> predicate)
>>>>
>>>>     // Explicit factory
>>>>     <T, C extends Collection<T>> Tabulator<T, C[]>
>>>>     partition(Predicate<T> predicate,
>>>>               Supplier<C> rowFactory)
>>>>
>>>>     // Partitioned mutable reduce
>>>>     <T, D> Tabulator<T, D[]>
>>>>     partition(Predicate<T> predicate,
>>>>               MutableReducer<T,D> downstream)
>>>>
>>>>     // Partitioned functional reduce
>>>>     Tabulator<T, T[]>
>>>>     partition(Predicate<T> predicate,
>>>>               T zero,
>>>>               BinaryOperator<T> reducer)
>>>>
>>>>     // Partitioned functional map-reduce
>>>>     Tabulator<T, T[]>
>>>>     partition(Predicate<T> predicate,
>>>>               T zero,
>>>>               Function<T, U> mapper,
>>>>               BinaryOperator<T> 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
>>>
>