<html><head><meta http-equiv="Content-Type" content="text/html; charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class="">On Jan 14, 2020, at 3:05 PM, Brian Goetz <<a href="mailto:brian.goetz@oracle.com" class="">brian.goetz@oracle.com</a>> wrote:<br class=""><div><blockquote type="cite" class=""><br class="Apple-interchange-newline"><div class="">
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8" class="">
<div class="">
<br class="">
<blockquote type="cite" cite="mid:342885299.1329242.1579042844517.JavaMail.zimbra@u-pem.fr" class="">
<div style="font-family: arial, helvetica, sans-serif; font-size: 12pt;" class="">
<div data-marker="__QUOTED_TEXT__" class="">
<div class=""><br class="">
</div>
<div class="">This is almost OT but it's a question I was asked for
twice,<br class="">
</div>
<div class="">what is the rational to use the angle bracket instead of
the parenthesis ?<br data-mce-bogus="1" class="">
</div>
</div>
</div>
</blockquote>
<br class="">
I surveyed a variety of implementations of toString(), and picked
what seemed most common, which was some variant of: <br class="">
<br class="">
Type[v=vVal, u=uVal]<br class="">
<br class="">
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.<br class=""></div></div></blockquote><br class=""></div><div>In practice record-ness will be clear at a glance from the class name.</div><div><br class=""></div><div>I see no downsides to the existing syntax and am (like Brian) uninterested</div><div>in exploring alternatives to this particular punctuation polarity.</div><div><br class=""></div><div>— John</div><div><br class=""></div><div>P.S. …OK, in the interests of defending this position FTR, here’s</div><div>some additional rationale. This is not intended as an invitation to</div><div>explore other designs which might have better rationales!</div><div><br class=""></div><div>A record is, first of all, a tuple, with an immediate proviso that it’s</div><div>nominal, having a named type and named components. As a tuple</div><div>it’s sequential and heterogeneous. As a nominal entity its components</div><div>are keyed, allowing strongly type access. It is not indexed like a</div><div>homogeneous entity.</div><div><br class=""></div><div><div>Lists, arrays, and sets print with square brackets, and records like them</div><div>are sequential data structures (though heterogeneous), so they too print</div><div>with square brackets.</div><div><br class=""></div><div>Unlike lists and arrays, the nominal information is added as decorations.</div><div><br class=""></div><div>The decorations follow the precedent of (Abstract)Map, but the</div><div>similarity to Map is not close enough to mandate closer similarly</div><div>to Map syntax. In particular, Maps are not (usually) ordered,</div><div>and cannot be interpreted (usually) without reference to keys.</div><div>Records unlike maps are always ordered and can be interpreted</div><div>as pure tuples (as well as maps).</div><div><br class=""></div><div>Record: heterogeneous, sequential, keyed, N[a=x,b=y].</div><div>tuple*: heterogeneous, sequential, indexed, (x,y).</div><div>List, array: homogeneous, sequential, indexed, [x,y].</div><div>Set: homogeneous, non-sequential, self-keyed, [x,y].</div><div><div>Map: homogeneous, non-sequential, keyed, {a=x,b=y}.</div><div><br class=""></div><div>See also:</div><div>MethodHandle: MethodHandle(A)T</div><div class=""><div>MethodType: (A)T</div></div><div class=""><br class=""></div></div><div>(*) hypothetical in Java, math notation cited.</div><div><br class=""></div><div><br class=""></div></div></body></html>