About renaming "equals(Object,Object)" as "deepEquals(Object,Object)"...
Simone Giannecchini a écrit :
> Could you please, clarify a bit further (just for the records :-))?
> Then we can improve/integrate these classes and call it a day :-)
EqualsUtils.equals(Object,Object) or Resources.deepEquals(Object,Object)
performs 9 "if (x instanceof y)" checks before to fallback on x.equals(y).
However in a majority of cases we are comparing objects that can not be array
(e.g. File, String, etc.), in which case the above checks are overhead.
Checking for array in all cases is safer, but is useful only in a very small
fraction of cases. Even when we have arrays, in the majority of cases we can
invoke directly (I mean with array type known at compile-time) one of the
Arrays.equals(...) methods.
So I suggest to rename the current "equals(Object,Object)" method as
"deepEquals" exactly as in Resources so that developper invokes it (together
with is 9 "if (x instanceof y)" checks) only when he know that the values to be
compared are declared exactly as java.lang.Object (which means that they could
be arrays), not some Object subclasses (which means either that they can not be
arrays, or that some Arrays.equals(...) method can be invoked directly). I
suggest to keep "equals(Object,Object)" implemented in the same way than
"Resources.equals(Object,Object)". However if we want to make sure that it is
not used for arrays (so that developers invoke deepEquals(...) or
Arrays.equals(...) for those), we could consider doing that with assertions.
public static boolean equals(Object a, Object b) {
if (a == b) {
return true;
}
if (a == null) {
return false;
}
assert !a.getClass().isArray() : a.getSimpleName();
assert b == null || !b.getClass().isArray() : b.getSimpleName();
return a.equals(b);
}
However it is a deprecated practice to use assertions for argument checks in
public API. So either we keep such "equals" utility methods in an internal
class
like Resources, or either we don't apply assertions. Or we could decide to make
an exception to this principle and document this assertion in the javadoc.
Martin
-------------------------------------------------------------------------
This SF.net email is sponsored by the 2008 JavaOne(SM) Conference
Don't miss this year's exciting event. There's still time to save $100.
Use priority code J8TL2D2.
http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone
_______________________________________________
Geotools-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/geotools-devel
