Equals() in Sets and Collections

Question

It is a common knowledge that Collection per se are not supposed to have equals() method: first, comparing two bags (multisets) is too costly, second, comparing a Collection to a List may lead to ignoring the List order - the same elements but in different order is a different List, right?
Then I have a question: why does SortedSet have equals() method? It is definitely not just a Map, but a decorator; the order can be different. It is obviously an error.
Unlike the other clumsy feature:
Map<String> m1 = new HashMap();
Map<String> m2 = new HashMap();
m1.put("k", "v");
m2.put("k", "v");
m1.equals(m2); // returns true
m1.values().equals(m2.values()); // returns false - there is a long explanation why
Another, unrelated, observation.
String[] a1 = new String[] {"a", "b"};
String[] a2 = new String[] {"a", "b"};
a1.equals(a2); // returns false - bad, bad, bad implementation!
Arrays.asList(a1).equals(Arrays(asList(a2)); // returns true - way to go!

Answer 1

In which case my response is: It is?I think so. I can't say I've taken a survey, but I doubt that it's "common knowledge" that collections shouldn't override equals.
Otherwise you would end up comparing
Lists and Sets.Not if you follow the documented contracts.
the List order - the same elements but indifferent
order is a different List, right?List's equals contract requires that equals return
true iff the other object is also List and hasthe
same elements (by the elements' equals methods) in
the same order. You are repeating my explanation, are not you?No. I'm pointing out what you seem to have missed--that if you follow the documented contracts, there won't be a problem.
If you're aware of that and I missed you point, perhaps you could try to clarify what you're getting at?
Then I have a question: why does SortedSet have
equals() method? It is definitely not just aMap,
but
a decorator; the order can be different. It is
obviously an error.Set's equals contract only requires that the other
object also be a Set and that the two Sets contain
the same elements. Wrong. I mean, an ordered set is not equivalent to a
set. In your mind it is not. In the view taken by the collections framework, it can be. Neither view is inherently correct or wrong. I've never been in a situation to compare a SortedSet to a non-sorted Set (as far as I know), but I have compared Sets, and my own needs didn't care whether neither, one, or both of the Sets was sorted. So in the cases where I've compared Sets, the current definition has worked for me. I suppose there are cases where it doesn't work.
It has an additional structure: the order. Two
different ordered sets can have the same elements, it
does not mean they are the same. There's nothing inherent about equals() that says it has to compare every attribute or every structural aspect of the objects being compared.
It's math.But this is Java, which is intended to model certain mathematical concepts to a certain degree, but not necessarily to be perfectly faithful to them.
>
>
I suppose you could argue that for
SortedSets, order should matter for equality, buta)
I don't see any real benefit to it and b) You then
wouldn't be able to compare SortedSets to otherSets,
so the specific implementation would matter(unlike
for Maps and Lists).Well, here we are getting closer to the paradox. Of
course it would be interesting to compare SortedSets
as if they were ordinary Sets, and compare them to
Sets as well.As I said, I haven't knowingly done so, but I was glad that I didn't have to care whether they were sorted.
How about Lists? We may be interested in comparing
them too, ignoring the order. A List is an ordered
multiset. Why not compare Lists and Sets, as
Collections? I would not object - but the problem
lies somewhere deeper. Do you know where?I don't know that there is a problem. I'm not saying the current equals contracts are perfect, or that an objective "best" contract can be defined. But in my experience they have served well whenever I've needed them. I think they're a reasonable, practical compromise.
Weird. What is that explanation?values() returns a virtual Collection, a view that
has only an iterator which scans EntrySet and returns
Map.Entry.getValue().Okay. Still not sure why that would return false, but I'm not able to focus on it that much at the moment.
Yeah, I always thought it was odd that arrays'equals
methods didn't behave more like List's. I imagine
there's a reason for it, owing to how the array
classes are created, but still...What could be the reason? I'm just curious, that's
why I started this philosophical thread. :)I don't know, but one thing that's odd about arrays. There's no such class as MyClass[] until I create MyClass. Then MyClass[] magically comes into existence (or maybe the first time I use it). That makes the array classes different from other classes. I imagine it would have been possible to have them provide their own equals() that compares elements, but presumably it was deemed more difficult or complex or error-prone than the perceived value it would add.