----- Mail original ----- > De: "Gavin Bierman" <gavin.bier...@oracle.com> > À: "Remi Forax" <fo...@univ-mlv.fr> > Cc: "amber-spec-experts" <amber-spec-experts@openjdk.java.net> > Envoyé: Jeudi 4 Mars 2021 15:27:41 > Objet: Re: [External] : Re: Two new draft pattern matching JEPs
> Hi Remi, > > I know that Brian has already replied, but just to a couple of your points: > >> >> The traditional approach for guards cleanly separate the pattern part from >> the >> expression part >> case Rectangle(Point x, Point y) if x > 0 && y > 0 >> which makes far more sense IMO. >> >> The current proposal allows >> case Rectangle(Point x & true(x > 0), Point y & true(y > 0)) >> which is IMO far least readable because the clean separation between the >> patterns and the expressions is missing. > > Well it is, but that’s because you’ve written it in such a way. You could also > have written it: > > case Rectangle(Point x, Point y) & true(x > 0 && y > 0) > > which isn’t so different from the guards solution. As i said to Brian, i see this more as an issue, you have several ways to write exactly the same thing. You can see this as "Moar Powaer" or as what is the exact point of introducing a feature that less you express the same thing in twenty different ways. > >> >> There is also a mismatch in term of evaluation, an expression is evaluated >> from >> left to right, for a pattern, you have bindings and bindings are all >> populated >> at the same time by a deconstructor, this may cause issue, by example, this >> is >> legal in term of execution >> case Rectangle(Point x & true(x > 0 && y > 0), Point y) >> because at the point where the pattern true(...) is evaluated, the Rectangle >> has >> already been destructured, obviously, we can ban this kind of patterns to try >> to conserve the left to right evaluation but the it will still leak in a >> debugger, you have access to the value of 'y' before the expression inside >> true() is called. > > As Brian has pointed out, this pattern is actually ill-formed, as the `y` is > not > in scope in the guard pattern… yes, hence my "this is legal in term of execution", at the point where 'x' is know, 'y' is known too, so being able to specify a construct in between whn 'x' is known but 'y' is not yet visible make little sense. > > But thanks for the feedback. There are two issues here: expressivity and > syntax. > With increased expressivity, of course you get more ways to write > difficult-to-understand code. Sometimes this is important enough for us to > reject expressivity, but mostly not. Syntax is, on the other hand, everyone’s > favourite subject :-) We could use pretty much any symbol as a pattern > operator. Your experience as an educator will certainly be very useful for us > to help determine the best choice if we go down this path - do you have any > suggestions ? I think it's still a little too soon to talk about syntax. > > Cheers, > Gavin > > PS: I know you left this as a red flag, but just to say that I don’t recognise > this mission statement :-) > >> >> * Java does not invent things, it merely stole ideas from the other and make >> them > > its own in a coherent way For me, Java is like Picasso, first you stole, then you transcend. regards, Rémi
