> De: "John Rose" <john.r.r...@oracle.com> > À: "Guy Steele" <guy.ste...@oracle.com> > Cc: "Remi Forax" <fo...@univ-mlv.fr>, "Gavin Bierman" > <gavin.bier...@oracle.com>, "amber-spec-experts" > <amber-spec-experts@openjdk.java.net> > Envoyé: Samedi 6 Mars 2021 00:36:53 > Objet: Re: Two new draft pattern matching JEPs
> On Mar 5, 2021, at 2:41 PM, Guy Steele < [ mailto:guy.ste...@oracle.com | > guy.ste...@oracle.com ] > wrote: >>> 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. >> I would like to question your assertion >> bindings are all populated at the same time by a deconstructor >> Is this really necessarily true? > Same question from me, and I hope it’s not true. > And I see Brian has also piled on here! >> I would have thought that the job of the deconstructor is to provide the >> values >> for the bindings, and that int principle the values are then kept in >> anonymous >> variables or locations while the subpatterns are processed, one by one, from >> left to right. Because consider a more complex pattern: > For records that is true. But eventually I would say that the > job of the deconstructor is simply to provide some sort of > bundle of bits which might need more “cooking” in order > to unveil the components. Then, each occurrence of a > binding variable or a sub-pattern triggers that cooking, > but a don’t-care pattern (_ or …) does *not* trigger the > cooking. Who cares when something is cooked? Well, > if a component of an object is virtualized (NOT the case > with records) then it might cost something to reify it. > As a simple example, an array component might require > that an underlying array be defensively copied. > As a more subtle example, a RE-matching pattern > might require a lot of additional “cooking” to > reify the contents of an RE expression group. > So, my model of a deconstructor, in general, is > of one operation which produces a handle of > some sort, plus N additional operations which > optionally extract the N components. Or, almost > equivalently, it is a configurable method > which produces up to N values, based on how > it is invoked. (There’s a job for indy here.) > The body of a user-defined deconstructor could > exercise all these degrees of freedom, if there > were a way to “hook up” all of the out-vars, > but also provide an “out-var-requested” flag > for each one: > class PairOfArrays { > int[] a; int[] b; > __Deconstructor(out int[] aa, out int[] bb) { > if (aa requested) aa = a.clone(); > if (bb requested) bb = b.clone(); > } } > Here, the set of requested variables in the pattern > affects how much work the deconstructor does. It seems to be an early over-optimization, i really hope that yoiu can keep the deconstructor protocol far simpler and for your example piggyback on frozen arrays instead. > — John Rémi
