----- Mail original ----- > De: "Gavin Bierman" <gavin.bier...@oracle.com> > À: "John Rose" <john.r.r...@oracle.com> > Cc: "amber-spec-experts" <amber-spec-experts@openjdk.java.net> > Envoyé: Vendredi 12 Mars 2021 11:11:46 > Objet: Re: Guards redux
> Thanks everyone for the discussion. I have updated the JEP: > > http://openjdk.java.net/jeps/8213076 > > It proposes *guarded patterns* of the form `p&&e`, as well as parenthesized > patterns, written `(p)`. Hi Gavin, nice, i find this version more appealing. In the first example that shows && as a guard, the example uses parenthesis which is my opinion should be removed case Triangle t && (t.calculateArea() > 100) -> System.out.println("Large Triangle"); if i read the grammar correctly, those parenthesis around the boolean expression are unnecessary case Triangle t && t.calculateArea() > 100 -> it will be more inline with the example above in the text that is using 'when' case Triangle t when t.calculateArea() > 100 -> Otherwise, in the document, the words "->-style" and ":-style" are hard to parse, i think array-style and colon-style are better terms. In the section "Dominance of pattern label", It's not clear to me if there is a dominance in between expressions, by example, can we have the following cases in that order ? case Foo(var a, var b) && a == 3: case Foo(var a, var b) && a == 3 && b == 4: for me the answer is yes, the dominance is computed on patterns only, not on expressions. > > I have left out AND and OR patterns, at least for now. Thanks to Guy we now > know > how to add them elegantly to the grammar when the time comes :-) When people > come to play with this, I’d be especially interested to hear about the need > for > AND and OR patterns. (I have a feeling that OR is more important, but that’s > another email...) > > Comments on the JEP very welcome. > > Thanks, > Gavin regards, Rémi > > >> On 11 Mar 2021, at 13:51, Gavin Bierman <gavin.bier...@oracle.com> wrote: >> >> Very clever, John. Yes, let’s not add any more puzzlers to the language! >> >>> On 10 Mar 2021, at 21:59, John Rose <john.r.r...@oracle.com> wrote: >>> >>> Good. PrimaryPattern is a good concept. >>> >>> On Mar 10, 2021, at 6:47 AM, Gavin Bierman <gavin.bier...@oracle.com> wrote: >>>> >>>> Guard: >>>> : AssignmentExpression >>> >>> I think it should be this instead: >>> >>> Guard: >>> : ConditionalAndExpression >>> >>> The effects of this narrower definition of a guard expression >>> are two: >>> >>> First, any guard of the form (a || b), (a ? b : c), or (a = b) >>> will require parentheses. >>> >>> Second, as a result, the following puzzlers will not be legal >>> inputs: >>> >>> case P && a || b: // compare x instanceof P && a || b >>> case P && a ? b : c: // compare x instanceof P && a ? b : c >>> case P && a = b: // compare x instanceof P && a = b >>> >>> In all of these puzzlers, the “extremely fortuitous” >>> correspondence between the syntaxes of guarded >>> cases and instanceof’s with following boolean logic >>> are broken. >>> >>> The fix to align the meanings of the cases with the >>> instanceof’s is to add parentheses: >>> >>> case P && (a || b): // compare x instanceof P && (a || b) >>> case P && (a ? b : c): // compare x instanceof P && (a ? b : c) >>> case P && (a = b): // compare x instanceof P && (a = b) >>> >>> Using the modified grammar rule above forces the >>> coder to write the parentheses, I think. >>> >>> I think we should aim for “perfectly fortuitous” >>> here, not just “well, look how often the syntaxes >>> seem to mean the same thing although sometimes >>> they don’t”. Indeed, this is my main reason for >>> plumping for P && g in the first place. >>> >>> — John >>> >>>
