Equality

[John Rose]

On Dec 18, 2015, at 12:21 PM, Doug Lea <dl at cs.oswego.edu> wrote:
> 
> On 12/18/2015 12:48 PM, Brian Goetz wrote:
> 
>> So perhaps what this says is we are going to get pushed in the other direction
>> -- that we'll want to superate equals().
>> 
> 
> What if plain-equals and value-equals are independently overridable,
> with defaults:
>  boolean equals(any x) { return (x instanceof ThisClass) && equalValue(x); }
>  boolean equalValue(ThisClass x) { ... check bit equality … }

(And of course in that case make "equals" be "final" above value types.)

> (The equalValue method could be named "equals" too, but doing so
> is too confusing for now.)
> Where operator== calls equalValue, not plain equals.

That would go with Option 2 in my previous mail.
It's pretty and logical, but not clear yet if it is needed.

> The effects cascade to many of the Collection methods.

A big problem with collection methods is the effect of
the symmetry of equals in the presence of subtype polymorphism.
You can't tell which operand of equals is going to be a subtype of the other.

— John