> De: "Remi Forax" <[email protected]> > À: "Brian Goetz" <[email protected]> > Cc: "amber-spec-experts" <[email protected]> > Envoyé: Mercredi 6 Mai 2020 17:08:33 > Objet: Re: Swiss Cheese Issue - Revisit?
>> De: "Brian Goetz" <[email protected]> >> À: "Remi Forax" <[email protected]> >> Cc: "Manoj Palat" <[email protected]>, "amber-spec-experts" >> <[email protected]> >> 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" [ mailto:[email protected] | >>>> <[email protected]> ] >>>> À: "Manoj Palat" [ mailto:[email protected] | >>>> <[email protected]> ] , >>>> "amber-spec-experts" [ mailto:[email protected] | >>>> <[email protected]> ] >>>> 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
