[
https://issues.apache.org/jira/browse/LANG-588?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12830659#action_12830659
]
Matt Benson edited comment on LANG-588 at 2/7/10 6:03 AM:
----------------------------------------------------------
I'll respond to your first three comments in order:
* RE Javadoc of static methods: What are you looking for, beyond completing
the @param tags such that checkstyle is happy?
* RE @since: Okay.
* RE static imports: don't know what to say; 'tis a matter of opinion. If as
a community we turn out to fall in favor of not using static imports I will
abide.
WRT MatchedPair<T> as Iterable<T>, to be honest MatchedPair exists, in my mind,
mostly because only when the L and R types of Pair are the same can we provide
a typed Iterator. As for the tree walker concept, that never occurred to me
though I suppose I can see where you're coming from now that you mention it.
Perhaps your impression of a Pair as a LISP concept and my lack of similar
background account for the difference in perspective. However, as you
mentioned this would only really work if we sacrifice type-safety by making
Pair Iterable<Object>, and in that case it could be argued that the whole
notion of iterating over nested Iterables in depth-first or breadth-first
fashion could be extracted to a completely separate class, and be a more
versatile approach into the bargain, no?
In this case I'd be satisfied to drop MatchedPair as a class, drop Iterable
from Pair, and move matchedPairOf to Pair. Then I'd simply add:
{code}
public static <T> Iterator<T> pairIterator(final Pair<? extends T, ?
extends T> pair) {
return new Iterator<T>() {
private int index = -1;
public boolean hasNext() {
return index < 1;
}
public T next() {
if (index >= 1) {
throw new NoSuchElementException();
}
return ++index == 0 ? pair.left : pair.right;
}
public void remove() {
throw new UnsupportedOperationException();
}
};
}
{code}
was (Author: mbenson):
I'll respond to your first three comments in order:
* RE Javadoc of static methods: What are you looking for, beyond completing
the @param tags such that checkstyle is happy?
* RE @since: Okay.
* RE static imports: don't know what to say; 'tis a matter of opinion. If as
a community we turn out to fall in favor of not using static imports I will
abide.
WRT MatchedPair<T> as Iterable<T>, to be honest MatchedPair exists, in my mind,
mostly because only when the L and R types of Pair are the same can we provide
a typed Iterator. As for the tree walker concept, that never occurred to me
though I suppose I can see where you're coming from now that you mention it.
Perhaps your impression of a Pair as a LISP concept and my lack of similar
background account for the difference in perspective. However, as you
mentioned this would only really work if we sacrifice type-safety by making
Pair Iterable<Object>, and in that case it could be argued that the whole
notion of iterating over nested Iterables in depth-first or breadth-first
fashion could be extracted to a completely separate class, and be a more
versatile approach into the bargain, no?
> 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.
