Updated State of the Specialization

[Peter Levart]

On 12/21/2014 05:07 PM, Brian Goetz wrote:
> Value types need to have some form of at least some of the core Object 
> methods, at least hashCode, equals, and toString.  Open questions here 
> include:
>
>  - Will there be some interface that specifies these?  (C# has a root 
> interfaces like this that all structs implement)
>  - Will Object implement that interface?  (Seems nice for generic 
> code, but then it can't be called anything Value-ish, would have to be 
> called Object-ish, like "Objectionable" or "Objectifiable" or 
> "ObjectionYourHonor".)
>
> The compiler or VM would certainly generate default implementations of 
> equals/hashCode that delegates to the components.  A further open 
> question is whether these could be overridden by value types, or 
> whether this is just part of their definition.  (And, if 
> equals/hashCode are effectively final, its a little weird for toString 
> to be standing alone, though would be permissible.) 

I think default .equals() method for value types should be the bit-wise 
compare of all fields. I think this is a very important canonical equals 
and hard to implement in custom method easily (because of peculiarities 
of float and double). Like default equals for reference types, it is an 
equivalence relation with the greatest possible number of equivalence 
classes. The default .hashCode() method could then be some quick 
bit-wise sum of public fields. If there are no public fields, it would 
simply be 0. Value types holding sensitive information would then have 
to contain some public uniquifying field if they wanted to be used as 
keys in hash maps or implement a secure hash algorithm if they hold 
enough entropy.

Regards, Peter