valhalla-dev Digest, Vol 7, Issue 24

[Vitaly Davidovich]

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

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