Objects vs. values, the continuation

[Kevin Bourrillion]

On Sun, Apr 24, 2022 at 6:23 PM Remi Forax <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.

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.

-- 
Kevin Bourrillion | Java Librarian | Google, Inc. | kevinb at google.com