j.l.r.Parameter.hashCode() question

[elena votchennikova]

Hello Joe,

On 04.10.2013 21:14, Joe Darcy wrote:
> Hello Elena,
>
> On 10/04/2013 03:49 AM, elena votchennikova wrote:
>> Hi Joe,
>>
>> thank you for the replay,
>>
>> On 04.10.2013 5:03, Joseph Darcy wrote:
>>> Hello Elena,
>>>
>>> The general requirements from Object.hashCode hold: equal objects 
>>> must have equal hash codes. (Of necessity, unequal objects may have 
>>> the same hash code.)
>> Yep.
>>>
>>> The phrased "based on" means "some unspecified function of." It is 
>>> generally undesirable to exactly specify a hash code function when 
>>> you don't absolutely have to.
>> So, do you mean that the executable and the index are just used in 
>> this "unspecified function" or do you want to say that if the 
>> executable and the index are same, then the hash codes will be the same?
>>
>> I just want to clarify it, because if the answer is "yes" then I 
>> think this is not obviously from the wording "based on". And if the 
>> answer is "no", that this is Ok.
>> But in the spec to the equals() method we have the same wording: 
>> "Compares based on the executable and the index.". But what does this 
>> exactly mean?
>>
>>
>> Thank you for your help,
>> Elena
>
> It it implicit that the hashCode and equals mehtods on Parameter 
> follow the general hashCode and equals contract.
>
> Equality is based on executable and index; I don't think it is helpful 
> to write specification that is equivalent to the implementation of
>
>         if(obj instanceof Parameter) {
>             Parameter other = (Parameter)obj;
>             return (other.executable.equals(executable) &&
>                     other.index == index);
>         }
>         return false;
I think this is not obvious from the words "Compares based on the 
executable and the index" that Parameters are equals if 
"other.executable.equals(executable) && other.index == index".
If you mean exactly such check, it will be better to make the 
documentation more strong and mention this somehow. Because different 
implementations could weaken this contract and interpret this 
differently. Would it be Ok?
What do you think about it?


>
> We do not want to specify the hash function; it is sufficient to say 
> it takes the executable and index as inputs.

Sounds reasonable.

Thank you a lot,
Elena

>
> Cheers,
>
> -Joe