Swiss Cheese Issue - Revisit?

[Remi Forax]

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.goetz at oracle.com>
> À: "Manoj Palat" <manoj.palat at in.ibm.com>, "amber-spec-experts"
> <amber-spec-experts at 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.
>> [1 [
>> http://mail.openjdk.java.net/pipermail/amber-spec-experts/2019-November/001835.html
>> |
>> http://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
>> |
>> https://mail.openjdk.java.net/pipermail/amber-spec-experts/2019-December/001837.html
>> ]
>> Regards,
>> Manoj
>> Eclipse Java Dev