Updated State of the Specialization

[David Chase]

On 2014-12-22, at 5:00 AM, Peter Levart <peter.levart at gmail.com> wrote:
> 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.

Could we be a little bit less excited about "quick" and a little bit more excited about the quality of the hashcode?
My one worry is whether we go for the reproducible hashcode that makes DOS slightly more possible but yields
reproducible results for testing and debugging, versus a "VM's choice" version of hashcode with constants that
vary from run to run that would thwart DOS.

I'm also tempted to say that hashcodes should include private fields but be overrideable, so anyone needing
true privacy would redefine hashcode and hopefully someone competent would implement it.  Including
private fields and using a decent hash function means that by default we probably get a better hashcode
than your average programmer (or James Gosling) would implement.

Also, in the state-of-the-specialization document, 1,$s/top-of-static/top-of-stack/
Someone's fingers were a little too well trained.

David