3 ms·
Yes, thanks, that's what I thought. BTW couple minor points: hashCode doesn't necessarily distinguish between objects (though most implementations would); and a
by 10ren 17y ago
Yes, thanks, that's what I thought. BTW couple minor points: hashCode doesn't necessarily distinguish between objects (though most implementations would); and an exception for mutable objects is collections (e.g. a Set is mutable, but you want to be able to compare sets).
- cousin_it 17y agoYes, I'd want to compare sets, but using == for that feels to me a dubious programming practice, akin to using + for set union. A special method like hasIdenticalContents() would make me more comfortable, the longer name removing equals-ambiguity for readers and reflecting the nontrivial computation behind the scenes. And that would mesh nicely with other set operations like difference and containment that would be getting non-canonical names anyway... Also, if you make Set.equals() depend on contents, you'll have to change the implementation of hashCode as well, wreaking havoc on sets containing mutable sets. So you really should only override equals() if your class is immutable or you're feeling especially exotic.
- 10ren 17y agoYour comment made no sense, then when I started to write a reply requesting clarification, it refreshed, and you'd added more. I feel much better now that it makes sense; and I'll watch out for the live-edit-comment in future (I do live-edit myself too). But I'll say that naming is tricky, since programming languages are really human languages, and as such are affected by the familiarity of their specific users as much (or, at times, more) than pure logic. Highly illogical, I know. EDIT: The present implementation of Set.equals() depends on contents; it's independent of hashCode, and there's no problem with sets of sets.