equals and hashCode

[Mark Thornton]

On 30/10/12 11:15, Aleksey Shipilev wrote:
> On 10/26/2012 11:38 PM, Brian Goetz wrote:
>> Yes, it is decided: lambdas will inherit the implementation of
>> equals/hashCode from Object.  So, that means no relief for the use case
>> you are raising here.
> Just to clarify, because someone else was asking me this.
>
> 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;
>   Mapper mref1 = ((Integer)0)::compareTo;
>   Mapper mref2 = ((Integer)0)::compareTo;
>   Mapper mref3 = (new Integer(0))::compareTo;
>   Mapper mref4 = (new Integer(0))::compareTo;
>   Mapper smref1 = Integer::parseInt;
>   Mapper smref2 = Integer::parseInt;
>
> 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

Mark Thornton