Re: Next up for patterns: type patterns in switch

Hello! I haven't read all the discussions in this thread, so sorry if my points were already covered. It looks like relocating the problem to defaults have a hole for this trivial switch: switch(obj) { case null: // fallthrough default: } If we think that default case always throws for

Re: [records] Mark generated toString/equals/hashCode in class files somehow?

Note that the javax.lang.model API already exposes that information: https://docs.oracle.com/en/java/javase/14/docs/api/java.compiler/javax/lang/model/util/Elements.html#getOrigin(javax.lang.model.element.Element) This as a case where there can be higher fidelity when a source file vs a class

Re: Next up for patterns: type patterns in switch

OK, I’m going to make some *concise* responses to what appear to be the choice points in your Email. I’m going to leave aside the JEP document[1] for now. [1]: https://cr.openjdk.java.net/~briangoetz/amber/pattern-match.html On Jun 24, 2020, at 7:44 AM, Brian Goetz wrote: > ... > ## Patterns

Re: Next up for patterns: type patterns in switch

> De: "Brian Goetz" > À: "Guy Steele" > Cc: "Remi Forax" , "John Rose" , > "amber-spec-experts" > Envoyé: Jeudi 13 Août 2020 16:24:11 > Objet: Re: Next up for patterns: type patterns in switch >>> I agree destructuring is just as important as conditionality and those two >>> things should be

Re: A peek at the roadmap for pattern matching and more

P.S. I’m going to take Brian’s lead now and talk about the short-term matters immediately in front of us. It’s been fun… We’ll get back it later. > On Aug 13, 2020, at 5:17 PM, John Rose wrote: > > On Aug 13, 2020, at 4:53 PM, fo...@univ-mlv.fr > wrote: >> >> use

Re: A peek at the roadmap for pattern matching and more

First, recall that I asked already that we table this digression; I provided the peek because several folks asked me for some more context, not to distract us with a shiny bikeshed. Second, I get what you are saying -- I really do, because I've been exactly there on my long and winding

Re: A peek at the roadmap for pattern matching and more

On Aug 13, 2020, at 4:53 PM, fo...@univ-mlv.fr wrote: > > use it as an anonymous carrier of values to transfer the values from a plain > old class to a representation you can do destructuring on it Yes, something like that could play a role in reifying a “bundle of names coming out of a block”,

Re: Next up for patterns: type patterns in switch

> De: "Guy Steele" > À: "Remi Forax" > Cc: "Brian Goetz" , "John Rose" > , "amber-spec-experts" > > Envoyé: Jeudi 13 Août 2020 19:22:46 > Objet: Re: Next up for patterns: type patterns in switch >> On Aug 13, 2020, at 8:19 AM, [ mailto:fo...@univ-mlv.fr | fo...@univ-mlv.fr ] >> wrote: >> . .

Re: A peek at the roadmap for pattern matching and more

- Mail original - > De: "John Rose" > À: "Remi Forax" > Cc: "Guy Steele" , "Brian Goetz" > , "amber-spec-experts" > > Envoyé: Vendredi 14 Août 2020 01:24:13 > Objet: Re: A peek at the roadmap for pattern matching and more > On Aug 13, 2020, at 4:11 PM, fo...@univ-mlv.fr wrote: >> >>

Re: Next up for patterns: type patterns in switch

On 7/23/2020 11:52 AM, Brian Goetz wrote: On 7/23/2020 2:38 PM, Remi Forax wrote: On guards, they do not work well with exhaustiveness. Still not sure they are useful. It works fine, it's just more work for the user to get right. We induce a domination ordering on patterns.  If `T <: U`,

Re: A peek at the roadmap for pattern matching and more

On Aug 13, 2020, at 4:11 PM, fo...@univ-mlv.fr wrote: > > For me it's like having a complex lock on the front door and wanting to have > the same mechanism on the opposite side of the front door (to go out) because > you already know how to unlock the front door. Ow! Tough crowd. As you may

Re: A peek at the roadmap for pattern matching and more

> De: "John Rose" > À: "Guy Steele" > Cc: "Remi Forax" , "Brian Goetz" , > "amber-spec-experts" > Envoyé: Jeudi 13 Août 2020 23:37:47 > Objet: Re: A peek at the roadmap for pattern matching and more > On Aug 13, 2020, at 12:39 PM, Guy Steele < [ mailto:guy.ste...@oracle.com | >

Re: A peek at the roadmap for pattern matching and more

On Aug 13, 2020, at 3:01 PM, Guy Steele wrote: > >> >> On Aug 13, 2020, at 5:37 PM, John Rose > > wrote: >> >> On Aug 13, 2020, at 12:39 PM, Guy Steele > > wrote: >>> >>> Whereas I can more easily understand that the job of >>> >>>

Re: A peek at the roadmap for pattern matching and more

> On Aug 13, 2020, at 5:37 PM, John Rose wrote: > > On Aug 13, 2020, at 12:39 PM, Guy Steele > wrote: >> >> Whereas I can more easily understand that the job of >> >> public deconstructor Point(int x, int y) { >> x = this.x; >> y = this.y;

Re: A peek at the roadmap for pattern matching and more

What you said! On Aug 13, 2020, at 1:14 PM, Brian Goetz wrote: > > By framing deconstructors as the arrow-reversed form of constructors, we > provide the missing edges in our graph in a symmetrical way. By framing > deconstruction as merely a "multi-getter", we may provide the missing edges,

Re: A peek at the roadmap for pattern matching and more

On Aug 13, 2020, at 12:39 PM, Guy Steele wrote: > > Whereas I can more easily understand that the job of > > public deconstructor Point(int x, int y) { > x = this.x; > y = this.y; > } > > is to take values out of the object “this” and put them into separate >

Last call on pattern switch (well, not really)

So, what happened is what always happens on mailing lists -- I put out a multi-page writeup reflecting hundreds of hours of research and incorporating years of discussion, and 99% of the discussion was a too-loud, back-and-forth thread on a relatively uninteresting corner case on the subject

Re: A peek at the roadmap for pattern matching and more

> De: "Brian Goetz" > À: "Remi Forax" > Cc: "amber-spec-experts" > Envoyé: Jeudi 13 Août 2020 22:28:52 > Objet: Re: A peek at the roadmap for pattern matching and more > This was meant to be a sneak peek, for context, not an invitation to argue > about > the syntax. Was it a mistake to share

Re: A peek at the roadmap for pattern matching and more

> De: "Guy Steele" > À: "Remi Forax" > Cc: "Brian Goetz" , "amber-spec-experts" > > Envoyé: Jeudi 13 Août 2020 21:39:33 > Objet: Re: A peek at the roadmap for pattern matching and more >> On Aug 13, 2020, at 9:06 AM, [ mailto:fo...@univ-mlv.fr | fo...@univ-mlv.fr ] >> wrote: >> . . . >> ok,

Re: A peek at the roadmap for pattern matching and more

This was meant to be a sneak peek, for context, not an invitation to argue about the syntax.  Was it a mistake to share it at this time? (And remember the rule: don't comment on syntax until you've said everything you have to say about the model, because otherwise nothing else will ever get

Re: A peek at the roadmap for pattern matching and more

> De: "Brian Goetz" > À: "Remi Forax" > Cc: "amber-spec-experts" > Envoyé: Jeudi 13 Août 2020 15:42:40 > Objet: Re: A peek at the roadmap for pattern matching and more >> We want a destructor, a destructor is a method that returns a list of values >> the >> same way a constructor takes a list

Re: A peek at the roadmap for pattern matching and more

Whereas I can more easily understand that the job of     public deconstructor Point(int x, int y) {         x = this.x;         y = this.y;     } is to take values out of the object “this” and put them into separate _variables_, not a new object.  (Granted, these variables have a

Re: A peek at the roadmap for pattern matching and more

> On Aug 13, 2020, at 9:06 AM, fo...@univ-mlv.fr wrote: > > . . . > ok, let's take a step back because i think the current proposal has fall in a > kind of local maximum in term of design. > > We want a destructor, a destructor is a method that returns a list of values > the same way a

Re: A peek at the roadmap for pattern matching and more

> On Aug 13, 2020, at 9:42 AM, Brian Goetz wrote: > > . . . >> i should wuth by example a method minMax that returns both the minimum and >> the maximum of an array > >> public static (int min, int max) minMax(int[] array) { > > Nope. Not going there. I went down this road too, but

Re: Next up for patterns: type patterns in switch

> On Aug 13, 2020, at 8:19 AM, fo...@univ-mlv.fr wrote: > > . . . > > I wonder if we find it natural only because we are used to use the keyword > "default" inside a switch, . . . I think that may be so; but given that it is so, I am happy to exploit that fact! > I think i prefer using

Re: Next up for patterns: type patterns in switch

>> I agree destructuring is just as important as conditionality and those two >> things should be orthogonal. >> But i still think having a keyword to signal that a pattern (not a case) is >> total is better than letting people guess. I’m glad this discussion has moved to the right thing —

Re: A peek at the roadmap for pattern matching and more

> We want a destructor, a destructor is a method that returns a list of values > the same way a constructor takes a list of parameters. > The way to represent that list of value is to use a record. Yes, already been down that road, I did an entire sketch of this feature where we expose

Re: A peek at the roadmap for pattern matching and more

> I'm not able to parse "super(var aa)", it's not a pattern we have not talk > about. > And "super" is "this" typed as the superclass and with the method calls on it > using invokespecial instead of invokevirtual. It’s a straightforward duality to constructor-super relationships. In a

Re: A peek at the roadmap for pattern matching and more

> De: "Brian Goetz" > À: "Remi Forax" > Cc: "amber-spec-experts" > Envoyé: Jeudi 13 Août 2020 03:51:51 > Objet: Re: A peek at the roadmap for pattern matching and more >> In the code: >> public deconstructor B(int a, int b) { >> super(var aa) = this; >> a = aa; >> b = this.b; >> } >> i believe

Re: A peek at the roadmap for pattern matching and more

> De: "Brian Goetz" > À: "Remi Forax" > Cc: "amber-spec-experts" > Envoyé: Jeudi 13 Août 2020 03:51:51 > Objet: Re: A peek at the roadmap for pattern matching and more [...] >> I know that you have consider something like this, but i prefer making the >> deconstructor a method returning a

Re: A peek at the roadmap for pattern matching and more

- Mail original - > De: "John Rose" > À: "Remi Forax" > Cc: "Brian Goetz" , "amber-spec-experts" > > Envoyé: Jeudi 13 Août 2020 01:36:41 > Objet: Re: A peek at the roadmap for pattern matching and more > On Aug 12, 2020, at 4:28 PM, Remi Forax wrote: >> >> >> I know that you have

Re: Next up for patterns: type patterns in switch

> De: "Guy Steele" > À: "Remi Forax" > Cc: "Brian Goetz" , "John Rose" > , "amber-spec-experts" > > Envoyé: Jeudi 13 Août 2020 04:46:31 > Objet: Re: Next up for patterns: type patterns in switch >> On Aug 12, 2020, at 3:57 PM, [ mailto:fo...@univ-mlv.fr | fo...@univ-mlv.fr ] >> wrote: >> . .