Allow data interface and use non-deterministic hashCode

[Per Minborg]

Thanks for the clarification Brian. I think that makes sense. /Per


On 12/8/17 8:42 AM, Brian Goetz wrote:
>
>
> 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.
>

-- 

cid:F96D3A23-2EC0-48EF-9AD7-E8C2763D1551cid:00B98D15-D436-4C26-BFCF-B4FCCE0AACA4
*Per Minborg | CTO
*minborg at speedment.com
*US +*1 650 353 6579
*Skype: minborg
IM: @PMinborg
speedment.com <http://www.speedment.com/>*<http://www.speedment.com/>

JavaOne 2017 
<https://events.rainfocus.com/catalog/oracle/oow17/catalogjavaone17?search=minborg&showEnrolled=false>