Am 03.09.2015 18:29, schrieb Thibault Kruse:
So the anti-commutativity is broken in my example because
NumberAwareComparator because DefaultTypeTransformation.compareTo does
not perform symmetric checks (only 'left' needs to implement
Comparable, not 'right').
Maybe this could already be fixed by
DefaultTypeTransformation.compareTo requiring both arguments to be of
equivalent type, such as both being Comparables. And possibly as an
alternative fallback both being of the same class and having a
compareTo Method (which would break less groovy code I guess).
DefaultTypeTransformation.compareTo does something like that actually,
but not for numbers. And if you want to compare Double and Integer, it
won't work that way.
This could further be relaxed to also allow comparing two instances
*of the same class* when they have a compareTo method. But comparing a
MyNumber with an Integer should IMO fail in
DefaultTypeTransformation.compareTo().
Another problem of anti-commutativity arises due to the weird
hashCode() comparison that never returns 0, even when both hashCode
values are the same.
Maybe it would be better to compare the System hashcodes
System.identityHashCode(x) rather than the hashcodes from the objects.
Maybe that way even a 0 value could be returned then.
if both objects have referential identity
DefaultTypeTransformation.compareTo, will return 0. The method will also
handle null. What should we do if the hashcodes are the same, but the
objects are not? identityHashCode gives no guaranteee
Whether it makes sense at all to compare objects that way I don't know.
Comparing 0.0d and 0 as same without breaking equals-consistency seems
impossible, not sure what to do about that.
it is worse. compare 1.0G and 1.00G. BigDecimal.compare will say the are
euqal, BigDecimal.equals will say no.
bye blackdrag
--
Jochen "blackdrag" Theodorou
blog: http://blackdragsview.blogspot.com/
