[records] updates for Preview 9. hashCode

Daniel Heidinga 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 mailing list