I agree with you for the most part Martin. But if you look at some
implementations of equals, such as java.util.AbstractList, you will find
that it checks only that the object implements the interface and only
uses public methods to determine equality. Because only the interface
methods are used we don't have to worry about symmetry violations. You
get into trouble when you start casting to particular implementations.
I think the equals(and hashcode) methods should be fixed.
Jesse
Martin Desruisseaux wrote:
Justin Deoliveira a écrit :
I had a look at some of the style model objects implementations. I
notice the equals() methods all look for an instance of the same Impl
class, and not of the actual interface. For example FillImpl:
[...snip...]
Isn't this a problem? If someone comes along with their own
implementation of Fill, this comparison will fail even if they are
identifical in every other case.
The problem is not easy. An important part of the Object.equals(...)
contract is that 'equals' must be symmetric, i.e.:
x.equals(y) == y.equals(x)
Some algorithms, like some Collections, may behave in an unpredictable
way if this condition is not enforced.
If 'x' and 'y' are not of the same implementation class, then we have
no garantee that x.equals is implemented in the same way than
y.equals. We expose ourself to the risk of 'equals(...)' symmetry
violation, as well as some other potential violations like
transitivity. Looking for an instance of the same implementation class
in the 'equals' method is a conservative way to make sure that the
Object.equals(...) contract (especially symmetry) is respected.
If we want to look for interface instead of implementation, then the
details of the 'equals' method must be part of the specification (i.e.
the interface must declares explicitly an equals(...) method, and its
javadoc must explain how the comparaisons must be performed). This is
what Sun do for the java.util.Collection interface.
Martin.
-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through log
files
for problems? Stop! Download the new AJAX search engine that makes
searching your log files as easy as surfing the web. DOWNLOAD SPLUNK!
http://ads.osdn.com/?ad_idv37&alloc_id865&op=click
_______________________________________________
Geotools-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/geotools-devel
-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems? Stop! Download the new AJAX search engine that makes
searching your log files as easy as surfing the web. DOWNLOAD SPLUNK!
http://ads.osdn.com/?ad_idv37&alloc_id865&op=click
_______________________________________________
Geotools-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/geotools-devel
