Allow data interface and use non-deterministic hashCode

[Brian Goetz]

On 11/5/2017 4:49 PM, Per Minborg wrote:
> I am new to the mailing list so apologies if I'm asking questions 
> already understood.
>
> I have two questions/proposals:
>
> 1) I think it would make sense to allow data interfaces too. For 
> example, if I have an immutable model of a Point then we could have:
>
> __data interface Point(final int x, final int y) { }
>
> This would trivially correspond to the de-sugered interface:
>
> interface Point {
>     int getX();
>     int getY();
> }
>
> Now, one implementation of this interface would of course be:
>
> __data class GerneralPoint(final int x, final int y) implements Point { }
>
> and another could be
>
> class OrigoPoint() implements Point { public getX() {return 0;} public 
> getY() {return 0;} // Left out equals, hashCode and toString for brevity

While such an idea is not obviously silly, it seems to have pretty 
limited value, and also is not obviously consistent with the goal of the 
feature.  The design center for this feature is "better programming with 
plain data"; this allows class writers to say "this class doesn't need 
all the degrees of freedom that classes offer for decoupling 
representation from interface."  But for interfaces, which lack 
representation, this collapses to an (inflexible) mechanism for defining 
a bag of accessors.

> 2) How do we see the level of determinism on the generated hashCode() 
> methods (and toString())? There are several alternatives including:
>
> A) The hashCode() will always return the same value for the same input 
> state vector always and forever and may be deterministically 
> pre-computed and/or specified
>
> B) The hashCode() will always return the same value for the same input 
> state vector always and forever but the actual function is 
> implementation specific and is not available a-priori
>
> C) The hashCode() will always return the same value for the same input 
> state vector for any given Java version
>
> D) The hashCode() will always return the same value for the same input 
> state vector for any given compiled JAR/class file
>
> E) The hashCode() will always return the same value within a 
> particular running JVM instance
>
> It should be said that there are more alternatives. This is just a 
> sub-set of the ample variants that exists.

The base requirement for hashCode() is that equal objects have equal 
hash codes; further, data classes demand (politely request?) that 
equality and hash computation derive exclusively from the state vector.  
But I don't think its in anyone's interest to specify the hash algorithm 
(been burned by that with String).  If the object is deeply value-based 
then the hash code can be computed at compile time, which is a nice 
optimization, but just an optimization.