Equality

[Brian Goetz]

Good thought.  Let me give it a nudge in a direction: we'd like to get 
away from approaches that amount to partitioning on ref/val, and instead 
steer towards "here's the universal version, and here's the special-case 
version for refs that 'overrides' the universal version", where 
overriding could include things like perturbing the signature (as 
covariant overrides do.)

Recasting in this light:

     boolean equals(Something o) { ... } // total method

     <where ref T>
     boolean equals(Object o) { ... }  // ref-override

On 12/18/2015 3:21 PM, Doug Lea 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 ... }
>
> (The equalValue method could be named "equals" too, but doing so
> is too confusing for now.)
> Where operator== calls equalValue, not plain equals.
>
> The effects cascade to many of the Collection methods.
>
> -Doug
>
>