Swiss Cheese Issue - Revisit?
Brian Goetz
brian.goetz at oracle.com
Wed May 6 18:03:33 UTC 2020
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 <forax at univ-mlv.fr>
> Sent by: "amber-spec-experts"
> <amber-spec-experts-bounces at openjdk.java.net>
> To: Brian Goetz <brian.goetz at oracle.com>
> Cc: amber-spec-experts <amber-spec-experts at openjdk.java.net>
> Subject: [EXTERNAL] Re: Swiss Cheese Issue - Revisit?
> Date: Wed, May 6, 2020 9:07 PM
> ------------------------------------------------------------------------
>
> *De: *"Remi Forax" <forax at univ-mlv.fr>
> *À: *"Brian Goetz" <brian.goetz at oracle.com>
> *Cc: *"amber-spec-experts" <amber-spec-experts at openjdk.java.net>
> *Envoyé: *Mercredi 6 Mai 2020 17:08:33
> *Objet: *Re: Swiss Cheese Issue - Revisit?
>
> ------------------------------------------------------------------------
>
> *De: *"Brian Goetz" <brian.goetz at oracle.com>
> *À: *"Remi Forax" <forax at univ-mlv.fr>
> *Cc: *"Manoj Palat" <manoj.palat at in.ibm.com>,
> "amber-spec-experts" <amber-spec-experts at 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.goetz at oracle.com>
> <mailto:brian.goetz at oracle.com>
> *À: *"Manoj Palat" <manoj.palat at in.ibm.com>
> <mailto:manoj.palat at in.ibm.com>,
> "amber-spec-experts"
> <amber-spec-experts at openjdk.java.net>
> <mailto: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
>
>
>
More information about the amber-spec-observers
mailing list