valhalla-dev Digest, Vol 7, Issue 24
vitalyd at gmail.com
Fri Jan 9 16:42:58 UTC 2015
Honestly, it's going to be terrible if people can't provide their own
equals/hashCode for value types. What's the rationale for that?
Also, special casing == for just value types doesn't seem appealing as it
muddies the water and when I see == in code I have to go check whether it's
value types or not to figure out what's going to happen.
Sent from my phone
On Jan 9, 2015 11:37 AM, "Simon Ochsenreither" <simon at ochsenreither.de>
> > 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
> The combination of 1 and 3 sounds terrible, imho. :-)
> a) Until now, people could expect that == had a fixed, non-changeable
> interpretation. With that strategy, it could do arbitrary things.
> b) Additionally it conflates two different concepts: Low-level identity
> and high-level equality.
> c) Plus, with references we had to worry whether equals was implemented
> or was just using the default implementation of pointer identity. With
> that strategy we would create the reverse problem: Using ==, we would
> have to wonder whether it was just the default implementation or someone
> overrode it.
> What's wrong with the strategy I proposed earlier?
More information about the valhalla-dev