As I understand, Hoss just pointed out that the method that was added
creates confusion in the mind of the users as to why they were added, what
do they do, and how are they different from the previous methods in terms
of usage.
If we have that documented, we'd at least have a clear understanding of
when to use what method. Also, if the thought was that getKey and getValue
don't make sense for Pair, it would have made sense to deprecate them with
documentation instead of having more methods that do the exact same thing.

I don't think there's an argument here, just a mail thread.

On Wed, May 4, 2016 at 12:00 PM, Ishan Chattopadhyaya <
ichattopadhy...@gmail.com> wrote:

> I think for a "Pair" class, getKey and getValue has no meaning. A pair
> need not be a key/value pair. A key and a value are required for a map
> entry.
> first()/second() or left()/right(), both make sense to me. Perhaps
> removing getKey() and getValue() methods should be removed.
>
> On Thu, May 5, 2016 at 12:18 AM, Chris Hostetter <hossman_luc...@fucit.org
> > wrote:
>
>>
>> : There is no harm in having multiple 'getter' names. getKey() and
>> getValue()
>> : doesn't offer enough explanation  in many cases where it is used
>>
>> getKey and getValue are fundementaly descriptive names -- particularly
>> when they are the only methods in a class named "Pair".
>>
>> As soon as you start adding more methods, with names that are in no way
>> descriptive, *alongs side of* the exsting getKey and getValue methods, you
>> not only add methods that are confusing, but you increase the confusion as
>> to the meanining behind the other names.
>>
>> the fact that these methods do *exactly* the same thing should be a big
>> fucking red flag that people looking at the API (w/o looking at hte
>> implementation) will wonder "what do i use each of these methods for? how
>> is getKey() diff from _1()?"
>>
>> *THAT* is why you need javadocs.
>>
>> If the entirety of the class was...
>>
>> class Pair<K,V> {
>>   K _1();
>>   V _2();
>> }
>>
>> ...then no one would bat an eye, but as soon as you start adding redundent
>> methods, you raise questions about how they are diff and why they exist.
>>
>> Imagine for a moment that the "Closable" interface looked like this...
>>
>> interface Closable {
>>   void close();
>>   void close_1();
>> }
>>
>>
>> ...wouldn't you wnat some fucking javadocs on those methods so you'd have
>> some clue what the point of them where?
>>
>>
>> :
>> : On Wed, May 4, 2016 at 11:56 PM, Scott Blum <dragonsi...@gmail.com>
>> wrote:
>> :
>> : > Or left() and right()
>> : >
>> : > On Wed, May 4, 2016 at 2:18 PM, Ishan Chattopadhyaya <
>> : > ichattopadhy...@gmail.com> wrote:
>> : >
>> : >> Another option to consider could be: first() and second()
>> : >>
>> : >> C++ uses it: http://www.cplusplus.com/reference/utility/pair/
>> : >>
>> : >> On Wed, May 4, 2016 at 11:44 PM, Noble Paul <noble.p...@gmail.com>
>> wrote:
>> : >>
>> : >>> The names getKey() and getValue() are not always relevant for a pair
>> : >>> object. it's not necessarily a key and value. In that case, it
>> makes sense
>> : >>> to use the index .
>> : >>>
>> : >>>
>> : >>> This is a convention followed Scala. Tuple2 (
>> : >>> http://www.scala-lang.org/api/rc2/scala/Tuple2.html ) to Tuple10 (
>> : >>> http://www.scala-lang.org/api/rc2/scala/Tuple10.html)
>> : >>>
>> : >>> On Wed, May 4, 2016 at 4:32 AM, Chris Hostetter <
>> : >>> hossman_luc...@fucit.org> wrote:
>> : >>>
>> : >>>>
>> : >>>> WTF is this?
>> : >>>>
>> : >>>> why are these (poorly named) alternatives for getKey and getValue
>> : >>>> useful?
>> : >>>>
>> : >>>>
>> : >>>> : Date: Tue,  3 May 2016 15:09:08 +0000 (UTC)
>> : >>>> : From: no...@apache.org
>> : >>>> : Reply-To: dev@lucene.apache.org
>> : >>>> : To: comm...@lucene.apache.org
>> : >>>> : Subject: lucene-solr:master: added a couple of extra methods
>> : >>>> :
>> : >>>> : Repository: lucene-solr
>> : >>>> : Updated Branches:
>> : >>>> :   refs/heads/master 0ebe6b0f7 -> 184da9982
>> : >>>> :
>> : >>>> :
>> : >>>> : added a couple of extra methods
>> : >>>> :
>> : >>>> :
>> : >>>> : Project: http://git-wip-us.apache.org/repos/asf/lucene-solr/repo
>> : >>>> : Commit:
>> : >>>> http://git-wip-us.apache.org/repos/asf/lucene-solr/commit/184da998
>> : >>>> : Tree:
>> : >>>> http://git-wip-us.apache.org/repos/asf/lucene-solr/tree/184da998
>> : >>>> : Diff:
>> : >>>> http://git-wip-us.apache.org/repos/asf/lucene-solr/diff/184da998
>> : >>>> :
>> : >>>> : Branch: refs/heads/master
>> : >>>> : Commit: 184da9982c55fac4735abf01607e4f8f70eb5749
>> : >>>> : Parents: 0ebe6b0
>> : >>>> : Author: Noble Paul <noble.p...@gmail.com>
>> : >>>> : Authored: Tue May 3 20:34:36 2016 +0530
>> : >>>> : Committer: Noble Paul <noble.p...@gmail.com>
>> : >>>> : Committed: Tue May 3 20:34:36 2016 +0530
>> : >>>> :
>> : >>>> :
>> ----------------------------------------------------------------------
>> : >>>> :  solr/solrj/src/java/org/apache/solr/common/util/Pair.java | 8
>> : >>>> ++++++++
>> : >>>> :  1 file changed, 8 insertions(+)
>> : >>>> :
>> ----------------------------------------------------------------------
>> : >>>> :
>> : >>>> :
>> : >>>> :
>> : >>>>
>> http://git-wip-us.apache.org/repos/asf/lucene-solr/blob/184da998/solr/solrj/src/java/org/apache/solr/common/util/Pair.java
>> : >>>> :
>> ----------------------------------------------------------------------
>> : >>>> : diff --git
>> : >>>> a/solr/solrj/src/java/org/apache/solr/common/util/Pair.java
>> : >>>> b/solr/solrj/src/java/org/apache/solr/common/util/Pair.java
>> : >>>> : index 423f94c..f87323c 100644
>> : >>>> : --- a/solr/solrj/src/java/org/apache/solr/common/util/Pair.java
>> : >>>> : +++ b/solr/solrj/src/java/org/apache/solr/common/util/Pair.java
>> : >>>> : @@ -27,6 +27,14 @@ public class Pair<K, V> implements
>> Serializable {
>> : >>>> :
>> : >>>> :    private V value;
>> : >>>> :
>> : >>>> : +  public K _1() {
>> : >>>> : +    return key;
>> : >>>> : +  }
>> : >>>> : +
>> : >>>> : +  public V _2() {
>> : >>>> : +    return value;
>> : >>>> : +  }
>> : >>>> : +
>> : >>>> :    public V getValue() {
>> : >>>> :      return value;
>> : >>>> :    }
>> : >>>> :
>> : >>>> :
>> : >>>>
>> : >>>> -Hoss
>> : >>>> http://www.lucidworks.com/
>> : >>>>
>> : >>>>
>> ---------------------------------------------------------------------
>> : >>>> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
>> : >>>> For additional commands, e-mail: dev-h...@lucene.apache.org
>> : >>>>
>> : >>>>
>> : >>>
>> : >>>
>> : >>> --
>> : >>> -----------------------------------------------------
>> : >>> Noble Paul
>> : >>>
>> : >>
>> : >>
>> : >
>> :
>> :
>> : --
>> : -----------------------------------------------------
>> : Noble Paul
>> :
>>
>> -Hoss
>> http://www.lucidworks.com/
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
>> For additional commands, e-mail: dev-h...@lucene.apache.org
>>
>>
>


-- 
Anshum Gupta

Reply via email to