I now have authoristion from OpenGamma to discuss adding a Pair class
to [lang] based on our internal classes. If necessary a CCLA can be
signed, although since we are not necessarily importing the OpenGamma
classes as is and I'd be writing code in [lang3] with my Apache hat
on, the CCLA might not be needed. I can also code it in work time :-)
The main goal would be either an abstract class or an interface for
Pair. We chose an abstract class so that it could have factory
methods:
Pair<String, Number> p = Pair.of("Foo", 6);
It also allowed more control over the immutability of Pair (although
because its abstract and holds references to any object, immutability
cannot be guaranteed).
We then have other concrete classes:
- ObjectsPair - two generified objects
- DoublePair - two double
- IntDoublePair - int and double
- LongDoublePair - long and double
- IntObjectPair - int and generified object
- LongObjectPair - long and generified object
Clearly there are many more possible combinations, but some make less
sense than others. (Booleans don't waste space, as they are a
singleton reference, short/float are rarely used)
Beyond this, there are some standard comparators.
Design wise, we implement Map.Entry (makes sense). The primitive
classes implement primitive map entry interfaces from another library,
but that wouldn't make sense here. They are comparable and
serializable (again, one reason for an abstract class).
We name our elements "first" and "second".
The elements are available by methods (for generics) or as public
final variables from the concrete classes (not the abstract one). The
methods are getFirst(), getSecond() plus getKey() and getValue() for
Map compatibility.
The pairs are implemented as immutable. I saw someone mention the
possibility of a mutable pair, so perhaps we consider that.
I don't want this to be a long process of design or implementation! If
there isn't rapid consensus, I'd suggest either shipping [lang3] with
or without the existing class.
Opinions?
Stephen
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
