[records] updates for Preview 9. hashCode
forax at univ-mlv.fr
forax at univ-mlv.fr
Wed Jan 15 01:02:11 UTC 2020
> De: "John Rose" <john.r.rose at oracle.com>
> À: "Brian Goetz" <brian.goetz at oracle.com>
> Cc: "Remi Forax" <forax at univ-mlv.fr>, "amber-spec-experts"
> <amber-spec-experts at openjdk.java.net>
> Envoyé: Mercredi 15 Janvier 2020 00:35:22
> Objet: Re: [records] updates for Preview 9. hashCode
> On Jan 14, 2020, at 3:05 PM, Brian Goetz < [ mailto:brian.goetz at oracle.com |
> brian.goetz at oracle.com ] > wrote:
>>> This is almost OT but it's a question I was asked for twice,
>>> what is the rational to use the angle bracket instead of the parenthesis ?
>> I surveyed a variety of implementations of toString(), and picked what seemed
>> most common, which was some variant of:
>> Type[v=vVal, u=uVal]
>> Which was good enough. Yes, we could bikeshed it, but I'm not particularly
>> seeing a problem that needs to be fixed, and it doens't seem obvious to me that
>> highlighting the record-ness of it is important at toString-time? It's the
>> state that matters.
> In practice record-ness will be clear at a glance from the class name.
> I see no downsides to the existing syntax and am (like Brian) uninterested
> in exploring alternatives to this particular punctuation polarity.
just for the sake of being exhaustive, the downsides are
- printing any combinations of list and records is hard to parse
record Book(String author, String title) {}
record Library(List<Book> books) { Library { books = List.copyOf(books); }}
var libraries = List.of(new Library(List.of(books1, books2)), ...)
libraries.toString()
return [Libary[books=[Book[author=..., title=...], Book[author=..., title=...]]], ...]
- as John said below the mathematical syntax for tuples is parenthesis not angle brackets.
And i'm not advocating for any changes, it's just intellectual honesty.
> — John
Rémi
> P.S. …OK, in the interests of defending this position FTR, here’s
> some additional rationale. This is not intended as an invitation to
> explore other designs which might have better rationales!
> A record is, first of all, a tuple, with an immediate proviso that it’s
> nominal, having a named type and named components. As a tuple
> it’s sequential and heterogeneous. As a nominal entity its components
> are keyed, allowing strongly type access. It is not indexed like a
> homogeneous entity.
> Lists, arrays, and sets print with square brackets, and records like them
> are sequential data structures (though heterogeneous), so they too print
> with square brackets.
> Unlike lists and arrays, the nominal information is added as decorations.
> The decorations follow the precedent of (Abstract)Map, but the
> similarity to Map is not close enough to mandate closer similarly
> to Map syntax. In particular, Maps are not (usually) ordered,
> and cannot be interpreted (usually) without reference to keys.
> Records unlike maps are always ordered and can be interpreted
> as pure tuples (as well as maps).
> Record: heterogeneous, sequential, keyed, N[a=x,b=y].
> tuple*: heterogeneous, sequential, indexed, (x,y).
> List, array: homogeneous, sequential, indexed, [x,y].
> Set: homogeneous, non-sequential, self-keyed, [x,y].
> Map: homogeneous, non-sequential, keyed, {a=x,b=y}.
> See also:
> MethodHandle: MethodHandle(A)T
> MethodType: (A)T
> (*) hypothetical in Java, math notation cited.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/amber-spec-experts/attachments/20200115/f16bb9b0/attachment.htm>
More information about the amber-spec-experts
mailing list