Relates :
|
|
Relates :
|
|
Relates :
|
|
Relates :
|
A DESCRIPTION OF THE REQUEST: The properties that the contract equals (found in Object) must fulfill, is the classical classification of equivalence, which is - reflexive: for all x, x=x - symmetric: for all x,y such that x=y, y=x - transitive: for all x,y,z such that x=y and y=z, x=z It is not possible to fulfill these properties when attributes can be added by extending the class. This is a fundamental problem of equivalence relations in object-oriented languages. More details on this can be found at http://developer.java.sun.com/developer/Books/effectivejava/Chapter3.pdf There is only one solution to this problem. Let C denote a set of classes such that for any two instances of these classes, we want to be able to check for the classical classification of equivalence. Then every class in C must agree on a single contract to be used when checking for equality, otherwise it is not possible to fulfill the properties above. JUSTIFICATION : As it is today, every class must implement or inherit the equality test using this common contract. At best, this will only increase redundancy, but at worst the implementation may lack symmetry or transitivity, creating bugs which in many cases can be hard to find. Further more, it is an indication that we need to implement equality in a more object oriented way when the method equals can not be shadowed within the set of classes C. EXPECTED VERSUS ACTUAL BEHAVIOR : EXPECTED - So how should this be implemented? The most evident way would be to let a third party determine the common contract as well as doing the actual checking. This will reduce redundancy, increase consistency, and most importantly, it makes sure that the properties of equivalence are fulfilled. In more detail, the third party would be an interface, much like the Comparator, but with an additional hashing method. More arguments for this solution can be found in bug reports 5087829, 4269596, 5045681, and 4771660. The only downside I can find is the increase of complexity, but this is a small price to pay, looking at what we gain.
|