equals and hashCode

[Aleksey Shipilev]

On 10/30/2012 03:42 PM, Ben Evans wrote:
> On Tue, Oct 30, 2012 at 11:23 AM, Mark Thornton <mthornton at optrak.com> wrote:
>> On 30/10/12 11:15, Aleksey Shipilev wrote:
>>>
>>> That means lambdas inherit the default implementations of
>>> equals/hashCode? It is as saying "you can't rely on equals()/hashCode()
>>> for lambdas, since you are not in control of those". Although one can
>>> piggyback on the factual behavior of lambdas, and we would have to
>>> explicitly say when the lambdas are considered to be equal (or not). I.e.:
>>>
>>>   Mapper lam1 = (x) -> x + 1;
>>>   Mapper lam2 = (x) -> x + 1;
>>>
>>> What are the expectations for equality? If we just inherit the default
>>> equals/hashCode, I would expect:
>>>
>>>   assertEquals(lam1, lam1);     // true
>>>   assertEquals(lam1, lam2);     // false
>>
>> I think that in this case the implementation is permitted but not
>> required to return true, i.e. lam1 == lam2 is possible but not guaranteed
> 
> This is a terrible idea.
> 
> Implementation-defined behaviour of something as fundamental as an
> equality operation is going to help no-one.

I would be happy with "lambda equality is not defined" clause somewhere
in the spec. The easiest way to implement this is to just let lambdas
inherit Object.hashCode()/equals(). Sticking with some particular
contract on lambda equality seems to counterfeit (possible) introduction
of function types.

-Aleksey.