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