cushon / issues-import

0 stars 0 forks source link

Calls to List.equals(Set) and vice versa #211

Open cushon opened 9 years ago

cushon commented 9 years ago

Original issue created by cpovirk@google.com on 2013-11-13 at 08:51 PM


(This differs from another check that I'm pretty sure was in development, the check for equals() on definitively unrelated types, because List and Set aren't definitively unrelated in the same way: As both are interfaces, there's nothing in the rules of inheritance that prevent a class from implementing both. However, given the way that their equals() methods are defined, a class still can't implement both.)

I was kind of excited about this check until my search of Google code found only a single instance. (Well, it found some other instances of issue 81, but that hardly counts, and it found some instances of tests that wanted to be sure that a particular List implementation was never equal to a particular Set implementation, but that's not helpful.) It's possible that people tend to find this bug in their own testing, but still, I'm kind of down on it now :\

cushon commented 9 years ago

Original comment posted by cpovirk@google.com on 2013-11-13 at 08:54 PM


(I also tried the test with SetMultimap vs. ListMultimap, which found no hits in Google code. Note also that I generalized both tests to check for Objects.equal() as well as a straight equals() call.)

cushon commented 9 years ago

Original comment posted by cpovirk@google.com on 2013-11-13 at 08:56 PM


Err, I messed up running the SetMultimap-ListMultimap test. I'll report back the real results shortly.

cushon commented 9 years ago

Original comment posted by cpovirk@google.com on 2013-11-13 at 09:06 PM


OK, I legitimately get zero hits from the SetMultimap-ListMultimap test (not even in tests, oddly enough).

cushon commented 9 years ago

Original comment posted by kevinb@google.com on 2013-11-13 at 09:39 PM


I'm not completely surprised because of how many people just put those in references of type Multimap.