Use Advanced Search to search the entire archive.
[jsr363-experts] Re: some things :)
- From: Werner Keil <
>
- To:
- Subject: [jsr363-experts] Re: some things :)
- Date: Sun, 14 Dec 2014 12:10:59 +0100
With that respect we treat different Unit implementations right, too;-)
BaseUnit.equals(BaseUnit) should always be true, just like
Integer.equals(Integer) is or BigInteger.equals(BigInteger), but as soon as
an operation may have a different result, say a TransfornedUnit, the new
class won't be equal to BaseUnit any more.
If we tried to consolidate that in a base class like AbstractUnit, etc. it
could work at least for all its known subclasses.
If another implementation then does its own equals() and hashCode() logic,
well see BigInteger and Integer;-)
Am 14.12.2014 04:45 schrieb "Martin Desruisseaux" <
>:
>
Le 14/12/14 00:44, Werner Keil a écrit :
>
>
Java and (Open)JDK have the most lousy equals() methods one can imagine.
>
See the Integer class:
>
if (obj instanceof Integer) {
>
return value == ((Integer)obj).intValue();
>
}
>
Which is why BigInteger.ONE.equals(Integer.valueOf(1)) will always
>
return false[?]
>
>
I see this definition as strict, not lousy. And I think that the JDK is
>
doing the right thing. If they were not so strict, it would be very
>
difficult to enforce the equals(Object) invariants mentioned in my
>
previous email.
>
>
>
Guess we can handle that better within an implementation like RI at
>
least.
>
>
Please read again my previous email about equals(Object) invariants (
>
*e.g.* A.equals(B) must imply B.equals(A), *etc.*). Wanting to handle
>
"better" often results in much worst situation. If the JDK implementations
>
perform strict comparisons, this is not because the developers were lazy.
>
>
Martin
>
>
Attachment:
362.gif
Description: GIF image