[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:
>
>https://urldefense.proofpoint.com/v2/url?u=https-3A__docs.oracle.com_
>javase_8_docs_api_java_lang_invoke_MethodHandle.html-23toString-2D-2D
>&d=DwIFaQ&c=jf_iaSHvJObTbx-siA1ZOg&r=LBQnmyrHQkEBElM8bAxhzfwLG2HbsYDd
>zEznFrQoob4&m=etTTBS9y5oovHJplsJwMyjctXyoPzqEdXAMgwJPDZqw&s=In8pAaJxE
>eJnblz_VUBj_JhiMndhS6hnbEK6rhceNdU&e=
>> 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.
--Dan
More information about the amber-spec-experts
mailing list