Hi Manoj, by "field" you mean only fields or everything in the scope with the same name, like capturable local variable with the same name.
Rémi > De: "Manoj Palat" <manoj.pa...@in.ibm.com> > À: "Remi Forax" <fo...@univ-mlv.fr> > Cc: "amber-spec-experts" <amber-spec-experts@openjdk.java.net>, "Brian Goetz" > <brian.go...@oracle.com> > Envoyé: Mercredi 6 Mai 2020 18:06:20 > Objet: RE: Swiss Cheese Issue - Revisit? > 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 <fo...@univ-mlv.fr> >> Sent by: "amber-spec-experts" <amber-spec-experts-boun...@openjdk.java.net> >> To: Brian Goetz <brian.go...@oracle.com> >> Cc: amber-spec-experts <amber-spec-experts@openjdk.java.net> >> Subject: [EXTERNAL] Re: Swiss Cheese Issue - Revisit? >> Date: Wed, May 6, 2020 9:07 PM >>> De: "Remi Forax" <fo...@univ-mlv.fr> >>> À: "Brian Goetz" <brian.go...@oracle.com> >>> Cc: "amber-spec-experts" <amber-spec-experts@openjdk.java.net> >>> Envoyé: Mercredi 6 Mai 2020 17:08:33 >>> Objet: Re: Swiss Cheese Issue - Revisit? >>>> De: "Brian Goetz" <brian.go...@oracle.com> >>>> À: "Remi Forax" <fo...@univ-mlv.fr> >>>> Cc: "Manoj Palat" <manoj.pa...@in.ibm.com>, "amber-spec-experts" >>>> <amber-spec-experts@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" [ mailto:brian.go...@oracle.com | >>>>>> <brian.go...@oracle.com> ] >>>>>> À: "Manoj Palat" [ mailto:manoj.pa...@in.ibm.com | >>>>>> <manoj.pa...@in.ibm.com> ] , >>>>>> "amber-spec-experts" [ mailto:amber-spec-experts@openjdk.java.net | >>>>>> <amber-spec-experts@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