> From: "Kevin Bourrillion" <kev...@google.com> > To: "Remi Forax" <fo...@univ-mlv.fr> > Cc: "valhalla-spec-experts" <valhalla-spec-experts@openjdk.java.net> > Sent: Monday, April 25, 2022 4:17:19 AM > Subject: Re: Objects vs. values, the continuation
> On Sun, Apr 24, 2022 at 6:23 PM Remi Forax < [ mailto:fo...@univ-mlv.fr | > fo...@univ-mlv.fr ] > wrote: >> As we discussed earlier, there are two approaches, one is to say that >> instance of class = object | value >> the other is to say that >> instance of class = object = reference object | immediate object >> I prefer the later to the former, because it does not goes against what >> people >> already think, > Please let us not mistake this: > BOTH choices involve redefining what a large number of people already think. > That is inescapable and is part of the cost of doing this project. > People think "all objects can be locked". We want to break that. They think > "everything I can access members on is an object". I want to break that. They > think "an object is always accessed via a reference". You want to break that. > Etc. etc. This is just what happens when there's been a missing quadrant for > decades. You have to change some existing assumptions, that's true, but you are proposing a kind of refactoring of the world before adding a new concept. It's easier to introduce a new form of something already existing. >>> One thing I like very much about this is that it fits perfectly with the >>> fact >>> that Integer is a subtype of Object and int is not. >> I've not a clear idea how primitive will be retrofit to be "immediate class" >> but >> at some point, we will want ArrayList<int> to be valid with E still bounded >> by >> Object, so the sentence "int is not a subtype of java.lang.Object" may be >> wrong >> depending how we retrofit existing primitive types. > No, this is my whole point. It's important for them to know that that is NOT > subtyping. (The only kind of subtyping people know and the only kind they > *should* think of is polymorphic subtyping.) They should continue to think of > "A is a subtype of B" as meaning that they can interact with a B that is > actually itself really an A; it's what Integer (but not int) gives you. This > relationship is called something else ("extends", maybe?) and is what array > covariance is also being rebased on. Again, subtyping is already an existing concept, there is no win in trying to scooby-doo it. We are introducing a new way to do subtyping, the subtyping between a java.lang.Object and a QPoint; and it's a form of subtyping porlymophism given that you can call toString/equals and hashCode. Rémi
