Consolidating the user model

[Kevin Bourrillion]

Certainly possible I'm just misunderstanding something. (I don't *think* I
am...)


On Wed, Nov 3, 2021 at 11:24 AM Dan Smith <daniel.smith at oracle.com> wrote:

> On Nov 3, 2021, at 11:23 AM, Kevin Bourrillion <kevinb at google.com> wrote:
>
> On Wed, Nov 3, 2021 at 9:02 AM John Rose <john.r.rose at oracle.com> wrote:
>
> > One way to thicken this thin argument is to say that Point is not really
> a class.
> > It’s a primitive.  Then it still has a value-set inclusion relation to
> Object, but it’s
> > not a sub-class of Object.  It is a value-set subtype.
>
> I would spin it like this: `Point` absolutely is a class. But its
> instances are *values* (like ints and references are, but compound), and
> values *are still not objects*.
>
> We've said at times we want to "make everything an object", but I think
> the unification users really care about is everything being a *class
> instance*.
>
> I think this fits neatly with the current design: `Point` has no
> supertypes*, not even `Object`, but `Point.ref` does.
>
> (*I mean "supertype" in the polymorphic sense, not the "has a conversion"
> sense or the "can inherit" sense. I don't know what the word is really
> supposed to mean. :-))
>
>
> These sorts of explanations make me uncomfortable—that a Point stored in a
> reference isn't really a Point anymore, but a "box" or something like that.
>

Yes exactly. I will be talking about why I think it's probably *good* to
think of it as a box.



> The problem is that you want to say that the Point gets converted to some
> other thing, yet that other thing:
> - is == to the original
>

I would hope that's already true of int==Integer?



> - provides the exact same API as the original
> - has the exact same behaviors as the original
>

Agreed that Point and Point.ref are different types that have the same
members/features.

One-class-multiple-types is not entirely without precedent (though, sure,
List<A> and List<?> and List don't have *exactly* the same API).

Once you accept that they're different types, then the fact they have the
same API is just convenient.


- works exactly like a class declared with original class's declaration
>

It's the same class. There's only one class.

(There are two java.lang.Classes, because what that type models is not
"class", it's something more like "an erased type or void" <handwave>.)


If you're telling people that when you assign a Point to type Object, they
> now have something other than a Point, they're going to want to *see* that
> somehow. And of course they can't, because the box is a fiction.
>

What would they want to see? What is there to see about an object? Maybe
its header, its dynamic type -- and uh, those things must be there, right?.
because how could I use it polymorphically otherwise. I'm not sure what
else would be meant by "seeing" the thing.

Fictions are great things when they don't leak. I don't see the leak here
yet.

I'll attempt to flip this around on you. :-) You say that a *value* of type
Point is also already an "object". But then where is its header, its
dynamic type? Objects have that. For whatever reason this seemed like the
more conspicuous leak to me.



> The reference vs. value story that we developed to address these problems
> (and problems that arise when you *do* let people "see" a real box) carries
> the right intuitions: you can handle a Point by value or by reference, but
> either way it's the exact same object, so of course everything you do with
> it will work the same.
>

I'm claiming this picture makes explaining the feature harder,
unnecessarily. An unhoused value floating around somewhere that I can
somehow have a reference to strikes me as quite exotic. Tell me it's just
an object and I feel calmer.

But I'll write a more proper explanation of why I think this is the wrong
retcon for "object".

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