commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Gary Gregory <>
Subject Re: [VOTE] Release Commons Lang 3.0 (RC1)
Date Thu, 03 Mar 2011 19:26:51 GMT
Hi All,

For my needs, I need something akin to a Smalltalk Association and the
current Pair works but it is not how I would like to see it implemented.

I want an interface and a generics-based implementation (like Pair.)

I find it weird to write "Map.Entry myAssoc = ..." but our Pair should
implement Map.Entry because M.E is a JRE interface just for this kind of
stuff even if the pair is not used in a Map.

How about this pseudo-code:

interface Pair extends Map.Entry (add some of our stuff in there if we need
class BasicPair<K,V> implements Pair.

Then we can talk about adding primitive Pairs.


On Thu, Mar 3, 2011 at 2:08 PM, Stephen Colebourne <>wrote:

> On 3 March 2011 18:56, Matt Benson <> wrote:
> > [SNIP]
> >> I don't love the new Pair class. We have an interface based version
> >> here at OpenGamma to allow primitive implementations for performance.
> >> I might be able to get our code released if there was interest.
> >
> > Providing interfaces without code that consumes them doesn't feel like
> > [lang]'s mission; this is akin to providing exceptions we don't use
> > IMHO.  It might be okay for Pair<L, R> to implement Map.Entry<L, R>,
> > for example.  But when you say primitive implementations, do you mean
> > implementations based around primitive types, or simplistic
> > implementations?  If the latter, how much more simplistic could it
> > get?
> Our OpenGamma pair is an abstract class (not an interface!):
> public abstract class Pair<A, B> implements Map.Entry<A, B>,
> Comparable<Pair<A, B>>, Serializable
> There are concrete implementations for ObjectsPair, DoublesPair,
> IntDoublePair etc. where the user can access the primitive type
> directly, or just use the base generified class. The question is
> whether [lang] wants no Pair, a simple one, or a full-featured one
> (where people may disagree on what full-featured should look like).
> Stephen
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> For additional commands, e-mail:

Thank you,

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message