Objects vs. values, the continuation

[forax at univ-mlv.fr]

> From: "Kevin Bourrillion" <kevinb at google.com>
> To: "Remi Forax" <forax at univ-mlv.fr>
> Cc: "valhalla-spec-experts" <valhalla-spec-experts at 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:forax at univ-mlv.fr |
> forax at 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 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/valhalla-spec-experts/attachments/20220425/54b0cc47/attachment.htm>