Equality (was: Re: Migrating methods in Collections)
brian.goetz at oracle.com
Fri Dec 18 16:55:18 UTC 2015
> 1. It seems unresolved in the current State of Values doc
> whether value types will have user-definable equals()
> methods. I think that this needs to be settled soon:
> If value types don't allow overriding equals, and if the implementation
> is "has same type and bits", then some of the problems you note
> almost disappear. For example c.contains(x) could be automatically
> translated into "false" if c is a collection of a different val type
> than x, or x is a ref type or null. Which also happens to catch all
> the type-problematic cases. I'm not sure how a compiler would know
> to do this though.
Here's the current thinking on the tools for equality:
- The bytecode set will provide sort of 'vcmpeq' instruction, whose
behavior is a componentwise recursive comparison (int fields with icmp,
value fields with vcmp, etc).
- The == operator in the language will correspond to vcmpeq
- The default (whether provided by javac or VM) implementation of
equals(V) for value types will do an == comparison
- Users can override equals(V)
The motivation for allowing overriding equals is the same as for
objects. Obvious examples include Decimal(1.0) and Decimal(1.00), and
Tuple[String,String] that both contain [ foo, bar ] but use different
String instances to do so.
On the signature of equality, equals() has potentially the same issue as
contains(), where you might want to accept a broader set of comparands.
Still figuring out the options there.
More information about the valhalla-spec-experts