Swiss Cheese Issue - Revisit?

[Brian Goetz]

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
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/amber-spec-experts/attachments/20200506/bb02896d/attachment.htm>