Affine transforms - matrix algebra: equals
pavel.safrata at oracle.com
Tue Aug 21 11:15:59 PDT 2012
On 21.8.2012 19:50, Martin Desruisseaux wrote:
> Hello all
> Le 22/08/12 02:34, Pavel Safrata a écrit :
>> there are some requests for implementing Transform.equals().
>> Determining whether or not two transforms equal may indeed be useful.
>> The question is: do we want to implement equals() and hashCode() and
>> thereby break usage of (mutable) Transforms in hash-based
>> collections? Or would some transformEquals(Transform) method do? I
>> like neither of those options. I would probably do as much as
>> possible to avoid implementing hashCode() for mutable objects but let
>> me first hear some opinions on this..
> I think that implementing equals(Object) without hashCode() would
> bring more trouble
This was of course never an option. I meant not implementing any of
them, because of the troubles caused by implementing hashCode().
> , since it would break the contract that a.equals(b) implies
> a.hashCode() == b.hashCode(). It may also cause some inconsistent
> behaviour in HashMap.get(a), which may or may not find b depending on
> whatever "by chance" the two Transforms have been put in the same slot
> (even if they have different hash code value).
> I think that a more conventional approach would be to implement both
> equals(Object) and hashCode(). There is plenty of mutable JDK classes
> implementing those methods (including HashMap itself!
It is not a common practice to put HashMaps as keys into HashMaps. But I
think there may be valid use-cases for mapping (animated) transforms to
> and all other standard collection implementations), so I would tend to
> believe that a majority of experienced Java developers know that they
> must not change any object stored as keys in such map...
More information about the openjfx-dev