Affine transforms - matrix algebra: equals

[Pavel Safrata]

Hello Martin,

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 
something..

Thanks,
Pavel

> 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...
>
>     Martin
>