Since locals can shadow fields, not allowing pattern variables to shadow
fields would likely seem to users as a strange kind of irregularity, and
they surely won't understand why they have to make up a new name. (And
worse, when they find out, they won't like the answer: because someone
else might write some confusing code.)
On 5/6/2020 12:06 PM, Manoj Palat wrote:
Hi Brian,
Our proposal was "disallowing a pattern variable to shadow a
field." - I don't see that this approach was tried from your mail.
Was this tried - Is there any problem which you see with this approach?
Regards,
Manoj
----- Original message -----
From: Remi Forax <fo...@univ-mlv.fr>
Sent by: "amber-spec-experts"
<amber-spec-experts-boun...@openjdk.java.net>
To: Brian Goetz <brian.go...@oracle.com>
Cc: amber-spec-experts <amber-spec-experts@openjdk.java.net>
Subject: [EXTERNAL] Re: Swiss Cheese Issue - Revisit?
Date: Wed, May 6, 2020 9:07 PM
------------------------------------------------------------------------
*De: *"Remi Forax" <fo...@univ-mlv.fr>
*À: *"Brian Goetz" <brian.go...@oracle.com>
*Cc: *"amber-spec-experts" <amber-spec-experts@openjdk.java.net>
*Envoyé: *Mercredi 6 Mai 2020 17:08:33
*Objet: *Re: Swiss Cheese Issue - Revisit?
------------------------------------------------------------------------
*De: *"Brian Goetz" <brian.go...@oracle.com>
*À: *"Remi Forax" <fo...@univ-mlv.fr>
*Cc: *"Manoj Palat" <manoj.pa...@in.ibm.com>,
"amber-spec-experts" <amber-spec-experts@openjdk.java.net>
*Envoyé: *Mercredi 6 Mai 2020 16:41:33
*Objet: *Re: Swiss Cheese Issue - Revisit?
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?
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'.
my fear is that in the end, when we have pattern matching, "if
instanceof" will always be seen as a poor's man pattern matching,
which it is, so nobody will use it so extending "if instanceof"
makes little sense.
Rémi
Rémi
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>
<mailto:brian.go...@oracle.com>
*À: *"Manoj Palat" <manoj.pa...@in.ibm.com>
<mailto:manoj.pa...@in.ibm.com>,
"amber-spec-experts"
<amber-spec-experts@openjdk.java.net>
<mailto: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
