<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>De: </b>"Brian Goetz" <brian.goetz@oracle.com><br><b>À: </b>"Remi Forax" <forax@univ-mlv.fr><br><b>Cc: </b>"Manoj Palat" <manoj.palat@in.ibm.com>, "amber-spec-experts" <amber-spec-experts@openjdk.java.net><br><b>Envoyé: </b>Mercredi 6 Mai 2020 16:41:33<br><b>Objet: </b>Re: Swiss Cheese Issue - Revisit?<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;"><font size="+1"><tt>I think I get what you are saying, but we didn't
go out of our way to _support_ it, we chose _not_ to go out of
our way to _disallow_ it. So it's not like we added a feature,
as much as didn't disable an interaction. <br><br>
Could you clarify what you mean?</tt></font></blockquote><div><br data-mce-bogus="1"></div><div>The pattern variable can be supported only in expression, we made an extra step to support it in the statement block following the expression, to extend the instanceof so the pattern variable go out of the scope the expression to the a part of the scope of an 'if' or 'while'.<br></div><div><br data-mce-bogus="1"></div><div>Rémi<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;"><br>
<div class="moz-cite-prefix">On 5/6/2020 10:21 AM, Remi Forax wrote:<br>
</div>
<blockquote cite="mid:1087261274.1702490.1588774908652.JavaMail.zimbra@u-pem.fr">
<div style="font-family: arial, helvetica, sans-serif; font-size:
12pt; color: #000000">
<div>I would like to add that the Swiss Cheese problem is
specific to instanceof, it's not a pattern matching issue per
se.</div>
<div>So there is another far easier solution to the Swiss Cheese
problem, don't support it because instanceof will be less
prominent in the future and instanceof in equals() can be
re-written to avoid the Swiss Cheese. <br>
</div>
<div><br>
</div>
<div>I'm afraid we have gone a step too far by trying to support
it.<br>
</div>
<div><br>
</div>
<div>Rémi<br>
</div>
<div><br>
</div>
<hr id="zwchr">
<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;"><b>De:
</b>"Brian Goetz" <a class="moz-txt-link-rfc2396E" href="mailto:brian.goetz@oracle.com" target="_blank"><brian.goetz@oracle.com></a><br>
<b>À: </b>"Manoj Palat" <a class="moz-txt-link-rfc2396E" href="mailto:manoj.palat@in.ibm.com" target="_blank"><manoj.palat@in.ibm.com></a>,
"amber-spec-experts"
<a class="moz-txt-link-rfc2396E" href="mailto:amber-spec-experts@openjdk.java.net" target="_blank"><amber-spec-experts@openjdk.java.net></a><br>
<b>Envoyé: </b>Mercredi 6 Mai 2020 15:02:13<br>
<b>Objet: </b>Re: Swiss Cheese Issue - Revisit?<br>
</blockquote>
</div>
<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;"><font size="+1"><tt>We experimented with a "cheese shield"
approach:<br><br>
- compute the scope(s) of a binding variable as a set
of position ranges: s0..e0, s1..e1, ...<br>
- compute the maximal scope for each variable: min(s0,
s1, ...) .. max(e0, e1, ...)<br>
- treat the gaps as implicitly shadowing fields of the
same name with an erroneous local<br><br>
If implementing the flow scoping is hard, I would think
implementing the shielded flow scoping is harder. The
reason is that, while we might think that there is a
"natural rectangular scope" for a binding, there really
isn't. So the shield gives you _two_ kinds of
irregularly-scoped things.<br><br>
But, design decisions should put the user first. So the
question is, whether the users are served better by:<br><br>
- having fragmented scopes, through which light can
shine, or<br>
- patching the holes so you cannot access the fields
without qualification, even though the corresponding
binding variable is "out of scope"<br><br>
And, it was really not clear which was the lesser of
evils here. There was some concern raised that this
seemed scarier than it really is because it is "new and
different", but not intrinsically bad. <br><br><br></tt></font><br>
<div class="moz-cite-prefix">On 5/6/2020 5:28 AM, Manoj
Palat wrote:<br>
</div>
<blockquote cite="mid:OF716683DA.45E4062E-ON00258560.0032F62C-00258560.003417C7@notes.na.collabserv.com">
<div class="socmaildefaultfont" dir="ltr" style="font-family:Arial, Helvetica,
sans-serif;font-size:10pt">
<div dir="ltr">Hi Brian, Gavin, all,</div>
<p dir="ltr">Referring to Tagir’s example in [1]</p>
<p dir="ltr">if
(obj instanceof String str) {</p>
<p dir="ltr">System.out.println(str.toLowerCase()); // str
refers to</p>
<p dir="ltr">pattern binding</p>
<p dir="ltr">}
else {</p>
<p dir="ltr">System.out.println(str.toLowerCase()); // str
refers to the field</p>
<p dir="ltr">}</p>
<p dir="ltr">which is mentioned as Swiss cheese issue in
the replies to [1]</p>
<p dir="ltr">From our development efforts in ecj
(Eclipse Compiler for Java) for this feature:</p>
<div dir="ltr">"swiss cheese" is hard for implementation
by compiler(atleast ecj) and understanding by users
alike. For conflicts *within a local scope* tools and
users can use a structural strategy to find the
nearest candidate declaration to which any name
reference should resolve, deferring to flow analysis
only the question, whether that resolution is legal.
This is not true for fields, where no structural
'proximity' applies.</div>
<p dir="ltr" style="outline: none">For that reason we
propose a compromise, whereby "swiss cheese" is
allowed for pattern variables, but disallowed for
fields shining through in the holes of the cheese.
This can be achieved by disallowing a pattern variable
to shadow a field. This is a significantly smaller
cost than having to invent cascades of names for a
cascade of pattern variables (the original motivation
for swiss cheese <span style="font-family: Times">–
as in Gavin’s message[2]).</span></p>
<p dir="ltr" style="outline: none">With this proposals
users have a chance to find a declaration by looking
only up and out starting from the point of reference.
For the implementation in ecj this makes a huge
difference, because admitting swiss cheese involving
fields would require us to abandon the strict
separation of compilation phases 'resolve' and 'flow
analysis'. Since this separation is one of the
fundamental design principles in the ecj compiler, a
change would require a major re-architecting of the
compiler, draining resources from other, high priority
tasks.</p>
<p dir="ltr" style="outline: none">In summary, we don't
object to using flow criteria to determine whether or
not a variable is in scope, we only object to flow
criteria to *select* between different same-named
variables, that could be in scope at the same
location. As far as we can see, this situation is
specific to fields and hence a change specific to
fields should avoid the major complexity.</p>
<p dir="ltr" style="outline: none">In a spec, one could
optionally generalize in a way that a pattern variable
may never shadow any other variable (local or field)
that is in scope.</p>
<div dir="ltr"><span style="font-family:Calibri
Light,sans-serif;"><span style="font-size:8.0pt;">[1</span></span><span style="font-family:Calibri Light,sans-serif;"><span style="font-size:8.0pt;"><a href="http://mail.openjdk.java.net/pipermail/amber-spec-experts/2019-November/001835.html" target="_blank">http://mail.openjdk.java.net/pipermail/amber-spec-experts/2019-November/001835.html</a></span></span><br>
</div>
<div dir="ltr"><span style="font-family:Calibri
Light,sans-serif;"><span style="font-size:8.0pt;">[2]
<u><span style="color:blue;"><a href="https://mail.openjdk.java.net/pipermail/amber-spec-experts/2019-December/001837.html" target="_blank">https://mail.openjdk.java.net/pipermail/amber-spec-experts/2019-December/001837.html</a></span></u></span></span><br>
</div>
<div dir="ltr"> </div>
<div dir="ltr">Regards,</div>
<div dir="ltr">Manoj</div>
<div dir="ltr">Eclipse Java Dev</div>
</div>
<br>
</blockquote>
<br>
<br>
</blockquote>
</div>
</div>
</blockquote>
<br><br></blockquote></div></div></body></html>