Package org.organicdesign.fp.tuple

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.

See: Description

Class Summary

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.

Package org.organicdesign.fp.tuple Description

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. Consider providing meaningfully named accessor methods. 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.