Am 03.09.2015 15:07, schrieb Thibault Kruse:
That's a long read.
and took hours to write
In a nutshell, it seems NumberComparator does
satisfy not the required anti-commutativity (
"The implementor must ensure that <tt>sgn(compare(x, y)) ==
-sgn(compare(y, x))</tt> for all <tt>x</tt> and <tt>y</tt>.") when
used for Non-Comparables:
x = new MyNumber(n: 1)
y = new Integer(0)
assert comp.compare(x, y) == - comp.compare(y, x)
| | | | | | | | | |
| -1 | 0 | 1 | -1 0 MyNumber(1)
| | |
org.codehaus.groovy.runtime.NumberAwareComparator@3e77a1ed
| | false
| MyNumber(1)
org.codehaus.groovy.runtime.NumberAwareComparator@3e77a1ed
And it is not "consistent with equals", which means it should not be
used with sorted Sets or Maps ("should be used with caution").
assert (comp.compare(new Float(0), new Integer(0)) == 0) == (new
Float(0).equals(new Integer(0)))
| | | | | | |
| |
| 0 0.0 0 true | 0.0
false 0
| false
org.codehaus.groovy.runtime.NumberAwareComparator@fe18270
Both violating anti-commutativity and not offering equals-consistency
make NumberAwareComparator an accident waiting to happen.
the tip of the iceberg, yes
So +1 for making that less Groovy-relaxed and more Java-strict. But I
would say that about many things, without care for breaking existing
code (Because that's the only way to move Groovy into more production
code in the world).
The Collection.minus() problem looks too complex to understand at a glance.
The question is, for both, what the change should be. If we want to
support being able to do "assert 1.00g == 1.0g", as well as "assert
1==1.0d" and if we want to mimic that with NumberAwareComperator, then
we have to violate "consistent with equals" and "anti-commutativity"
bye blackdrag
--
Jochen "blackdrag" Theodorou
blog: http://blackdragsview.blogspot.com/
