> De: "John Rose" <[email protected]> > À: "Brian Goetz" <[email protected]> > Cc: "Remi Forax" <[email protected]>, "amber-spec-experts" > <[email protected]> > 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:[email protected] | > [email protected] ] > 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.
