[
https://issues.apache.org/jira/browse/LANG-588?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12830876#action_12830876
]
Stephen Colebourne commented on LANG-588:
-----------------------------------------
I wouldn't cache the hash code in this class. If the pair contains a mutable
object, then the hash code of the mutable could change during the lifetime of
the Pair, causing the Pair hash code to break. Just calculate the hash code on
demand.
I'd also avoid MatchedPair if possible. I'd like to see Pair be final and
immutable (dependent on contained data).
I don't especially see the value of the iterator per se, but having a way to
convert a Pair to a list might be useful. That method could have an option to
expand any pairs it finds (and this could be built on an iterator internally,
rather than up front extraction...)
In general though, a [lang] Pair needs to be simple and non-religious :-)
> Create a basic Pair<L, R> class
> -------------------------------
>
> Key: LANG-588
> URL: https://issues.apache.org/jira/browse/LANG-588
> Project: Commons Lang
> Issue Type: New Feature
> Components: lang.*
> Reporter: Matt Benson
> Fix For: 3.0
>
> Attachments: MatchedPair.java, MatchedPairTest.java, Pair.java,
> PairTest.java
>
>
> [lang] is the perfect place to provide a basic typed Pair class. I have
> written such a class for my employer (who hasn't?) but can/will rewrite blind
> to avoid IP issues. I think it's also nice to go ahead and extend this to
> MatchedPair<T> extends Pair<T, T> as well.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
