[records] updates for Preview 9. hashCode
Daniel_Heidinga at ca.ibm.com
Tue Jan 14 14:49:23 UTC 2020
>P.S. Another way to deal with toString is just to specify exactly
>what we do (it’s not bad!) and follow up with a “subject to change”
>message. We took this tack with MethodHandle.toString:
>> Future releases of this API may add further information to the
>string representation. Therefore, the present syntax should not be
>parsed by applications.
This gets a +1 from me. The format is clear - explained so it's easy
to understand what the parts mean - and explicit that it may change.
We can't ever stop users from parsing #toString but this is explicit
that's a bad idea for them to do so.
More information about the amber-spec-experts