[records] updates for Preview 9. hashCode

[John Rose]

On Jan 13, 2020, at 4:23 PM, Kevin Bourrillion <kevinb at google.com> wrote:
> 
> On Thu, Jan 9, 2020 at 8:46 PM John Rose <john.r.rose at oracle.com <mailto:john.r.rose at oracle.com>> wrote:
> 
> All we need to do is promise
> that a record type’s hashCode fulfills the Object contract, especially
> relative to the record’s equals method.
> 
> Yes! This, exactly. Thank you.

You are welcome!

> (It doesn't even matter if the words in the spec technically admit the possibility it's implemented as `return 0`, because that's just a bad implementation, and specs shouldn't have the burden of saying "by the way this isn't/shouldn't be a bad implementation”.)

This is a good thing to remember when writing javadoc.  It gives us
permission to write less, or push information down into the “notes”.

> As for toString() it doesn't have the same "Object already says it all" situation, but I would question whether all the guarantees I currently see in the patch are really necessary. How do users benefit from those guarantees?  I do like the "equal values -> equal strings" one (perhaps noting that the inverse doesn't quite hold?).

OK, I updated the toString bit to say less following your suggestion:

+     * The precise format produced by this implicitly provided implementation
+     * is unspecified and is subject to change.
+     * It will, however, always be the case that equal records will
+     * report equal strings, under the reasonable assumption that the
+     * corresponding property holds for the component types.

How and if the component names and values appear is left unstated,
as a matter of QoI.

In some cases, a better QoI might lead to *less* string output, as when
a record has a rarely set optional value, and there’s little value to including
“, optval=Optional.empty” in most of the strings.

In some cases, a better QoI might lead to *more* string output, as when
a record has an array field and (somehow) it is determined that the displayed
value should use Arrays.toString instead of Object.toString.

Dunno how to turn on and off such tweaks, but maybe we figure that out
later, and in that case fewer promises about Record::toString makes for
more choices in the future.

— John