See: Description
Class | Description |
---|---|
Tuple10<A,B,C,D,E,F,G,H,I,J> |
Holds 10 items of potentially different types.
|
Tuple11<A,B,C,D,E,F,G,H,I,J,K> |
Holds 11 items of potentially different types.
|
Tuple12<A,B,C,D,E,F,G,H,I,J,K,L> |
Holds 12 items of potentially different types.
|
Tuple2<A,B> |
Holds 2 items of potentially different types, and implements Map.Entry (and UnmodMap.UnEntry
(there is no ImMap.ImEntry)).
|
Tuple3<A,B,C> |
Holds 3 items of potentially different types.
|
Tuple4<A,B,C,D> |
Holds 4 items of potentially different types.
|
Tuple5<A,B,C,D,E> |
Holds 5 items of potentially different types.
|
Tuple6<A,B,C,D,E,F> |
Holds 6 items of potentially different types.
|
Tuple7<A,B,C,D,E,F,G> |
Holds 7 items of potentially different types.
|
Tuple8<A,B,C,D,E,F,G,H> |
Holds 8 items of potentially different types.
|
Tuple9<A,B,C,D,E,F,G,H,I> |
Holds 9 items of potentially different types.
|
Immutable, type-safe, heterogeneous containers - ML calls these "records."
ML, Haskell, and Scala use tuples - why not Java?
Actually, tuples are *more* important in Java because Java does not have type aliases.
Instead of type aliases, extend tuples to give them descriptive names, and you can give descriptive names to the accessor methods as well.
Doing so is brief, ensures immutability, and provides correct, efficient equals()
, hashcode()
, and toString()
methods.
When you are experimenting, use tuples to leverage Java's type inference engine in fluent code so that you don't need to specify any types. When you decide to keep your experiment, extend tuples to give meaningful names to your data types and their fields. Look at UsageExampleTest.java (the unit test) to see why tuples are so important and flexible.
Copyright © 2017. All rights reserved.