Updated State of the Specialization

[Peter Levart]

On 12/22/2014 04:58 PM, Brian Goetz wrote:
> You're on the right track, but I think bitwise is the wrong answer; I 
> think the right answer is applying == componentwise.  Otherwise, if I 
> have a value type:
>
> value class DoubleHolder {
>     double val;
> }
>
> DoubleHolder d1 = "new" DoubleHolder(NaN);
> DoubleHolder d2 = "new" DoubleHolder(NaN);
>
> Under a componentwise ==, I get d1 != d2, just as I would with two 
> double values, but under a bitwise, I get d1 == d2.  This is exactly 
> the asymmetry I think you're trying to avoid!  Better to apply the 
> rule that two values are == iff all their components are ==.
>

The problem with double '==' is that it is not an equivalence relation 
(because of NaN value). And I think .equals() should be or some value 
types would be unsuitable for use as keys in hash maps. 
java.lang.Double.equals() does bitwise comparison for the same reason.

Perhaps an '==' operator could be defined for value types as 
component-wise '=='. It's just that default .equals() would not be the 
same as '==' for all value types then.

> But you say "default equals()".  Do you think this should be 
> overridable?  Or should this just be what == means, just as it does 
> for int?

This would not really be overriding in the sense of virtual methods. 
Javac could generate default equals()/hashCode() methods unless they are 
provided in source (like default constructors). The '==' operator could 
also be implemented as javac generated method.

I think it would be nice if .equals()/.hashCode() were user-definable 
for value types, yes. As with value-like classes, sometimes the author 
would not want all components to participate in equality tests, or would 
like to change the way some component is compared - in particular when 
components can also be pointers to objects (i.e. reference type components).

Regards, Peter

>
>> 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