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.
Could you clarify what you mean?
On 5/6/2020 10:21 AM, Remi Forax wrote:
I would like to add that the Swiss Cheese problem is specific to
instanceof, it's not a pattern matching issue per se.
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.
I'm afraid we have gone a step too far by trying to support it.
Rémi
------------------------------------------------------------------------
*De: *"Brian Goetz" <brian.go...@oracle.com>
*À: *"Manoj Palat" <manoj.pa...@in.ibm.com>, "amber-spec-experts"
<amber-spec-experts@openjdk.java.net>
*Envoyé: *Mercredi 6 Mai 2020 15:02:13
*Objet: *Re: Swiss Cheese Issue - Revisit?
We experimented with a "cheese shield" approach:
- compute the scope(s) of a binding variable as a set of position
ranges: s0..e0, s1..e1, ...
- compute the maximal scope for each variable: min(s0, s1, ...)
.. max(e0, e1, ...)
- treat the gaps as implicitly shadowing fields of the same name
with an erroneous local
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.
But, design decisions should put the user first. So the question
is, whether the users are served better by:
- having fragmented scopes, through which light can shine, or
- patching the holes so you cannot access the fields without
qualification, even though the corresponding binding variable is
"out of scope"
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.
On 5/6/2020 5:28 AM, Manoj Palat wrote:
Hi Brian, Gavin, all,
Referring to Tagir’s example in [1]
if (obj instanceof String str) {
System.out.println(str.toLowerCase()); // str refers to
pattern binding
} else {
System.out.println(str.toLowerCase()); // str refers to the field
}
which is mentioned as Swiss cheese issue in the replies to [1]
From our development efforts in ecj (Eclipse Compiler for
Java) for this feature:
"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.
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 – as in Gavin’s message[2]).
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.
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.
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.
[1http://mail.openjdk.java.net/pipermail/amber-spec-experts/2019-November/001835.html
[2]
_https://mail.openjdk.java.net/pipermail/amber-spec-experts/2019-December/001837.html_
Regards,
Manoj
Eclipse Java Dev
