Duplicate :
|
|
Relates :
|
|
Relates :
|
|
Relates :
|
|
Relates :
|
Collection.remove(Object) and Collection.contains(Object) must use the Object argument together with some kind of relation (hopefully an equivalence relation) to determine which elements qualify as being the "same" as the argument. As usual, it depends on what your definition of "is" is. The spec in Collection clearly states that the .equals() "equator" should be used. But some other obvious equators are likely to be desired by the user: - reference equality - the equator induced by a comparator, i.e. a "is" b iff c.compare(a,b) == 0 Resolving this satisfactorily is rather tricky. Probably the contract for contains/remove should be weakened, but it should be specified that contains and remove must use the SAME equator, the equator for ordered collections like SortedSet should be specified to be the equator induced by its ordering, and it should be required that each concrete collection class specify what equator is in use. PriorityQueue should use .equals() in spite of its having an ordering. Doug Lea wrote (in a slightly different context) "Here's my proposal for the easiest of them: In Collection, add to specs somewhere that any implementation using a comparator is free to use it as a equality function, and similarly for Comparables. (Wording this just right is a minor challenge.) ... Collection.contains() and friends have overly constraining specs. On the broader issue of whether there should be collection classes that allow user-defined equality functions, I think it would be OK to acommodate this, but only in classes that advertised their lack of guaranteed compliance to symmetry properties. (See disclaimers in IdentityHashMap), and that indicate that you are paying some overhead for the privilege. In the case of hash tables, this meshes with the informal proposal I put out to add a hash table class that is selectively (via constructor arguments) weak in key and/or value, and can use either identitiy or equals. Alternatively using an Equator seems like a reasonable thing to add to kill yet more birds with one stone. Josh is more than right to be wary of the cost of doing this sort of thing in existing classes. It's been a long while, but last time I tested such variants, the cost was very noticeable. I do not want to see further mandated slowdowns of core collection classes. It just drives people to use other collections packages." ###@###.### 2005-05-16 02:08:09 GMT
|