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 < [email protected]> 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 <[email protected] > > 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 <[email protected]> >> wrote: >> : >> : > Or left() and right() >> : > >> : > On Wed, May 4, 2016 at 2:18 PM, Ishan Chattopadhyaya < >> : > [email protected]> 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 <[email protected]> >> 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 < >> : >>> [email protected]> 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: [email protected] >> : >>>> : Reply-To: [email protected] >> : >>>> : To: [email protected] >> : >>>> : 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 <[email protected]> >> : >>>> : Authored: Tue May 3 20:34:36 2016 +0530 >> : >>>> : Committer: Noble Paul <[email protected]> >> : >>>> : 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: [email protected] >> : >>>> For additional commands, e-mail: [email protected] >> : >>>> >> : >>>> >> : >>> >> : >>> >> : >>> -- >> : >>> ----------------------------------------------------- >> : >>> Noble Paul >> : >>> >> : >> >> : >> >> : > >> : >> : >> : -- >> : ----------------------------------------------------- >> : Noble Paul >> : >> >> -Hoss >> http://www.lucidworks.com/ >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: [email protected] >> For additional commands, e-mail: [email protected] >> >> > -- Anshum Gupta
