commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Henri Yandell <>
Subject Re: [lang3] Pair
Date Fri, 04 Mar 2011 16:29:49 GMT
On Fri, Mar 4, 2011 at 3:41 AM, Stephen Colebourne <> wrote:
> 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 :-)

CCLA up to you and your company. You've signed a CLA so no concerns on my part.

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

Charge along with your ideas, once other topics are refined we can
branch 3.x off to 3.0 and refine that there while Pair continues if
need be.

I want to change the release style of Lang - I want to release every
couple of issues once we get Lang 3.0 out. Or every month. I want
3.0.68 to exist :) Missing the 3.0 date shouldn't be an issue at all
unless it's a backwards compat issue.


To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message