valhalla-dev Digest, Vol 7, Issue 24
brian.goetz at oracle.com
Fri Jan 9 16:25:34 UTC 2015
Yes, this is the plan.
As a possible implementation strategy:
- have == simply translate to invocation of .equals() for values
- have compiler/VM generate componentwise equals/hashCode
- maybe, or maybe not, permit developer to override said equals
> What's wrong with giving == and != a sensible implementation for value
> types as mentioned earlier? This would avoid introducing a new concept
> and would not require rewriting every equals/contains/... method in
>>> b) How is this different to the approaches already outlines earlier?
>> It provides a basic logical building-block (equality check) at the
>> language level, in a way that works both for primitives/valuetypes and
>> for nullable references. It addresses a very big long-standing pain
>> point in Java application development. It avoids writing/ or encouraging
>> "Duck.woof()" style-hacks -- null checks -- into a domain that does not
>> uniformly support them.
> Isn't this what was proposed earlier, just with == instead of
> introducing a new operator?
More information about the valhalla-dev