<html><body><div style="font-family: arial, helvetica, sans-serif; font-size: 12pt; color: #000000"><div><br></div><div><br></div><hr id="zwchr" data-marker="__DIVIDER__"><div data-marker="__HEADERS__"><blockquote style="border-left:2px solid #1010FF;margin-left:5px;padding-left:5px;color:#000;font-weight:normal;font-style:normal;text-decoration:none;font-family:Helvetica,Arial,sans-serif;font-size:12pt;"><b>From: </b>"Gavin Bierman" <gavin.bierman@oracle.com><br><b>To: </b>"Tagir Valeev" <amaembo@gmail.com><br><b>Cc: </b>"amber-dev" <amber-dev@openjdk.org>, "amber-spec-experts" <amber-spec-experts@openjdk.org><br><b>Sent: </b>Monday, October 3, 2022 5:29:40 PM<br><b>Subject: </b>Re: Draft JEPs: Pattern Matching for switch and Record Patterns<br></blockquote></div><div data-marker="__QUOTED_TEXT__"><blockquote style="border-left:2px solid #1010FF;margin-left:5px;padding-left:5px;color:#000;font-weight:normal;font-style:normal;text-decoration:none;font-family:Helvetica,Arial,sans-serif;font-size:12pt;">
Hi Tagir,
</blockquote><div><br></div><div>The main objection to remove the name of the record pattern is that it does not follow the principle of the data oriented programming.</div><div>The idea is that the data is more important than the code, or said differently, if the data change by example a component is added to a record, the compiler should flag all the code that uses that record and ask the user to modify the code.<br></div><div><br data-mce-bogus="1"></div><div>So a case with a record pattern is better than just a type pattern, because unlike a type pattern, a record pattern validates the shape of a record<br data-mce-bogus="1"></div><div> </div><div> case Point p // does not validate the shape of Point<br data-mce-bogus="1"></div><div> case Point(int x, int y) p // validates that a Point has two components x and y.</div><div><br data-mce-bogus="1"></div><div>When using virtual polymorphism, an operation is defined as an abstract method, so if the record shape changes, people will scan the rest of the record and change the implementation of the methods according to the new components. If the operation uses pattern matching, the record and the operation are not declared at the same place, so the compiler has to help users to find all the locations in the code that should be updated.<br data-mce-bogus="1"></div><div><br data-mce-bogus="1"></div><blockquote style="border-left:2px solid #1010FF;margin-left:5px;padding-left:5px;color:#000;font-weight:normal;font-style:normal;text-decoration:none;font-family:Helvetica,Arial,sans-serif;font-size:12pt;"><div class=""><br class="">
</div>
<div class="">So it was a number of issues actually. First, there is a nasty ambiguity problem. Consider:</div>
<div class=""><br class="">
</div>
<div class=""><font class="" face="Courier">record R(){} <br class="">
switch(e) { <br class="">
case R() when when (true) -> ... <br class="">
... <br class="">
} </font><br class="">
<br class="">
The label could be parsed as either: <br class="">
<br class="">
<font class="" face="Courier"> case (R() when) when (true) -> <br class=""></font><br class="">
or <br class="">
<br class="">
<font class="" face="Courier"> case (R()) when (when(true)) -> <br class=""></font><br class="">
(where `<font class="" face="Courier">when</font>` is a static boolean method). </div></blockquote><div><br></div><div>It's a usual issue with local keywords, we had the same kind of issue with the local keywords inside modules (transitive as a keyword or has a package name).<br data-mce-bogus="1"></div><div><br data-mce-bogus="1"></div><div>A solution on top of my head is to make "when" a keyword for the whole case (everything in between "case" and "->"), so having to consecutive "when" is not syntactically valid.<br data-mce-bogus="1"></div><div>It's not the only option, and i don't think it's a showstopper.<br data-mce-bogus="1"></div><div><br data-mce-bogus="1"></div><blockquote style="border-left:2px solid #1010FF;margin-left:5px;padding-left:5px;color:#000;font-weight:normal;font-style:normal;text-decoration:none;font-family:Helvetica,Arial,sans-serif;font-size:12pt;"><div class=""><br class="">
<div class=""><br class="">
</div>
<div class="">There is another issue which is this variable declaration is the only one in the language that can’t be annotated or marked as `final` which feels like a design smell. None of the obvious solutions to this looked good. </div></div></blockquote><div><br></div><div>For me, a group pattern is not really different than a type pattern for this concern,<br data-mce-bogus="1"></div><div>the current syntax is with a type pattern is<br data-mce-bogus="1"></div><div> case final Point p -><br data-mce-bogus="1"></div><div>so the syntax for a record pattern is<br data-mce-bogus="1"></div><div> case final Point(int x,int y) p -><br data-mce-bogus="1"></div><div><br data-mce-bogus="1"></div><div>It awkward and super verbose but it's a straight consequence of not having the binding always final.<br data-mce-bogus="1"></div><div><br data-mce-bogus="1"></div><blockquote style="border-left:2px solid #1010FF;margin-left:5px;padding-left:5px;color:#000;font-weight:normal;font-style:normal;text-decoration:none;font-family:Helvetica,Arial,sans-serif;font-size:12pt;"><div class="">
<div class=""><br class="">
</div>
<div class="">In most other languages with pattern matching they keep these two things - a destructing pattern and a naming pattern - separate. In both Haskell and Scala, they write `x@p` to “name” a pattern p as x. So that seems like a possibility. But for
now, we noted that in most cases you can rewrite pretty simply, e.g.</div>
<div class=""><br class="">
</div>
<div class=""><font class="" face="Courier"> case Point(var x, var y) when p.isVisible() -> </font></div>
<div class=""><br class="">
</div>
<div class="">can be rewritten:</div>
<div class=""><br class="">
</div>
<div class=""><font class="" face="Courier"> case Point p <br class="">
when p.isVisible() && p instanceof Point(var x, var y): …<br class=""></font><br class="">
or if it was in an instanceof:<br class="">
<br class="">
<font class="" face="Courier"> if (x instanceof Point p && p.isVisible() && p instanceof Point(var x, var y)) { … }</font></div>
<div><br class="">
</div>
<div>Neither of these versions read too badly.</div></div></blockquote><div><br></div><div>I disagree, a case ... does not exist in the vacuum but works and is read with the other cases.<br></div><div>Here, following "case Point p when ... ", you will have a proper record pattern of Point to be exhaustive and the lack of common prefix between the two patterns makes the code hard to read.<br data-mce-bogus="1"></div><div><br data-mce-bogus="1"></div><div> Point p = ...<br data-mce-bogus="1"></div><div> switch(p) {<br data-mce-bogus="1"></div><div> case Point p<br data-mce-bogus="1"></div><div> when p.isVisible() && p instanceof Point (var x, var y) -> ...<br data-mce-bogus="1"></div><div> case Point(int x, int y) -> ...<br data-mce-bogus="1"></div><div> }<br data-mce-bogus="1"></div><div><br data-mce-bogus="1"></div><div>compared to</div><div> <div> Point p = ...</div><div> switch(p) {</div><div> case Point(int x, int y) p when p.isVisible() -> ...</div><div> case Point(int x, int y) p -> ...</div><div> }</div><br data-mce-bogus="1"></div><div>Here, it's clear that the first line is a peculiar case of the second line.<br data-mce-bogus="1"></div><div><br data-mce-bogus="1"></div><blockquote style="border-left:2px solid #1010FF;margin-left:5px;padding-left:5px;color:#000;font-weight:normal;font-style:normal;text-decoration:none;font-family:Helvetica,Arial,sans-serif;font-size:12pt;"><div class="">
<div><br class="">
</div>
<div>Thoughts?</div>
<div><br class="">
</div>
<div>Gavin</div></div></blockquote><div><br></div><div>Rémi<br data-mce-bogus="1"></div><div><br data-mce-bogus="1"></div><div><br data-mce-bogus="1"></div><blockquote style="border-left:2px solid #1010FF;margin-left:5px;padding-left:5px;color:#000;font-weight:normal;font-style:normal;text-decoration:none;font-family:Helvetica,Arial,sans-serif;font-size:12pt;"><div class="">
<div><br class="">
</div>
<div><br class="">
<blockquote class="">
<div class="">On 3 Oct 2022, at 14:40, Tagir Valeev <<a href="mailto:amaembo@gmail.com" class="" target="_blank">amaembo@gmail.com</a>> wrote:</div>
<br class="Apple-interchange-newline">
<div class="">
<div class="">Hello!<br class="">
<br class="">
<blockquote class="">Remove support for named record patterns.<br class="">
</blockquote>
<br class="">
This surprises me. Probably there was a discussion about the rationale<br class="">
behind this change? Could you please point me? Thanks.<br class="">
<br class="">
With best regards,<br class="">
Tagir Valeev<br class="">
<br class="">
On Mon, Oct 3, 2022 at 2:48 PM Gavin Bierman <<a href="mailto:gavin.bierman@oracle.com" class="" target="_blank">gavin.bierman@oracle.com</a>> wrote:<br class="">
<blockquote class=""><br class="">
Dear all,<br class="">
<br class="">
The draft JEPs for the next preview of the Pattern Matching for switch and Record Patterns features are now available at:<br class="">
<br class="">
Pattern matching for switch: <a href="https://bugs.openjdk.org/browse/JDK-8294285" class="" target="_blank">
https://bugs.openjdk.org/browse/JDK-8294285</a><br class="">
Record Patterns: <a href="https://bugs.openjdk.org/browse/JDK-8294078" class="" target="_blank">https://bugs.openjdk.org/browse/JDK-8294078</a><br class="">
<br class="">
Comments welcomed!<br class="">
Gavin<br class="">
</blockquote>
</div>
</div>
</blockquote>
</div>
<br class="">
</div><br></blockquote></div></div></body></html>