Swiss Cheese Issue - Revisit?

[Brian Goetz]

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.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.
>
>         [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
>
>
>