One can argue that users would find usage of "x" confusing with reduced readability, and this can be the reason to warrant the usage of new names.
From: Brian Goetz <brian.go...@oracle.com>
To: Manoj Palat <manoj.pa...@in.ibm.com>, fo...@univ-mlv.fr
Cc: amber-spec-experts@openjdk.java.net
Subject: [EXTERNAL] Re: Swiss Cheese Issue - Revisit?
Date: Wed, May 6, 2020 11:34 PM
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.)
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émiRémiOn 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émiDe: "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.
Regards,ManojEclipse Java Dev
