commons-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Matt Benson (JIRA)" <j...@apache.org>
Subject [jira] Issue Comment Edited: (LANG-588) Create a basic Pair<L, R> class
Date Sun, 07 Feb 2010 06:04:27 GMT

    [ 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.


Mime
View raw message