On 4 March 2011 18:35, Matt Benson <gudnabr...@gmail.com> wrote:
> I agree that it would be nice to do whatever we're going to do
> quickly, and ship with *something*. On the other hand, I don't want
> to ship the existing class without consensus on design, only to give
> ourselves (and users) headaches trying to replace it in a subsequent
> release.
Since the existing Pair class can't be altered after the fact, we need
to ship without it, or code this up quickly.
> I also had the thought that the abstract class would be necessary for
> the factory methods. It doesn't seem important, but I'd really like
> to be able to say Pair.of(X, Y). Semantically it'd also be nice to be
> able to use fields on the immutable variety of Pair (it's perhaps
> debatable in light of JIT whether the final field access yields better
> performance, so I won't address it--but it *looks* faster :P ), while
> still requiring the client to know as little as possible about the RT
> type of the Pair. Is it possible to accomplish all these things?
>
> abstract class Pair<L, R> implements Map.Entry<L, R> {
> abstract L getLeft();
> abstract R getRight();
> final L getKey() { return getLeft(); }
> final R getValue() { return getRight(); }
> static <L, R> ImmutablePair<L, R> of(L, R) {}
> }
>
> class ImmutablePair<L, R> extends Pair<L, R> {
> final L left;
> final R right;
> ImmutablePair(L left, R right) { this.left = left; this.right = right; }
> L getLeft() { return left; }
> R getRight() { return right; }
> static <L, R> ImmutablePair<L, R> of(L, R) {}
> }
>
> class MutablePair<L, R> extends Pair<L, R> {
> private L left;
> private R right;
>
> MutablePair(L left, R right) { setLeft(left); setRight(right); }
> L getLeft() { return left; }
> setLeft(L left) { this.left = left; }
> R getRight() { return right; }
> setRight(R right) { this.right = right; }
> static <L, R> MutablePair<L, R> of(L, R) {}
> }
These class outlines are very similar to what I would propose from
OpenGamma. I'll need to check on Monday, but with those three classes
as they are above, I'd probably be happy.
> In the examples above I continue to use the left/right idiom for
> reasons of inertia; in the end, I don't *really* care. It seems
> examples abound of the various proposed paired names in other
> programming contexts, so this becomes a simple matter of taste and/or
> majority rules. Personally I prefer left/right as there is less
> connotation of priority given either member of the pair as (IMO) in
> the case of first/second.
Typically, the order is of some significance, as the generics force you to care.
> If we want to extend ImmutablePair for the wrapper types (it wouldn't
> seem to make sense to provide access to the primitive equivalent
> values in the MutablePair variety), where does it end? If we provide
> any such pair types, IMO we should use some predictable rule to
> define, for a given wrapper type, what combinations are available,
> e.g.:
>
> * X Double
> * X Boolean
> * X Object
> * X self
> * X * ?
I think that [lang] could probably stop with the three classes above,
and leave primitive implementations to others.
BTW, Pair is the right class name given how I've seen it discussed in
various places.
Stephen
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
