[External] : Re: Consolidating the user model

[Kevin Bourrillion]

On Thu, Nov 4, 2021 at 9:28 AM Dan Smith <daniel.smith at oracle.com> wrote:

> On Nov 3, 2021, at 6:19 PM, Kevin Bourrillion <kevinb at google.com> wrote:
>
> I think my intuitions about boxes tie heavily to 'getClass' behavior (or
>> some analogous reflective operation). "What are you?" should give me
>> different answers for a bare value and a box. A duck in a box is not the
>> same thing as a duck.
>>
>> The analogy here would be that Integer.getClass() returns Integer.class,
>> while int.getClass(), if it existed, would return int.class.
>>
>
> So far so good. If `int.getClass()` has to work at all, it might as well
> produce `int.class`, though it serves no actual purpose and we would just
> refactor it to `int.class` anyway. If `int.getClass()` won't even compile,
> it would be no great loss at all. The method exists for finding the dynamic
> type of an object; my model says "values are not objects and so have no
> dynamic type", which I think is good.
>
>
> But Point extends Object, and Object.getClass exists.
>

As does `wait()`. :-)  But absolutely, this case is different; I'm trying
to be clear that it seems *pointless but harmless* for
`someValue.getClass()` to be callable, so long as it returns whatever is
the most sensible thing according to the model adopted. Keeps static
refactoring tools in business!


Now, all that said, we could say by fiat that `getClass` is special and
> value types aren't allowed to invoke it. YAGNI. Except...
>

> I might want to write code like:
>>
>> <T extends Point.ref> void m(T arg) {
>>     if (arg.getClass() == Point.class) System.out.println("I'm a value!");
>>     else System.out.println("I'm a box!");
>> }
>>
>
> Someone might think this, but they can just ask themselves whether
> `int/Integer` work like that. They don't, so this doesn't either.
>
> int/Integer are a starting point, but our goal is to offer something more.
>

Just to be clear, my intention was only to say that under the
sure-they're-boxes model it would both "not work" and "not be expected to
work", which is at least harmonious. :-)


An implication of universal generics is that there needs to be some common
> protocol that works on both vals and refs. In the val/ref model, that
> protocol is objects: both vals and refs are objects with members that can
> be accessed via '.'. In the value/object model, I'm not quite sure how
> you'd explain it. Maybe there's a third concept here, generalizing how
> values and objects behave.
>

This is on point. I quite honestly forgot that "oh yeah, I don't fully
understand universal generics yet", and I'll go work on that. It might be
death to the model I'm clinging to, but in that case I'll become pretty
good at explaining to people why that model fails, so cool.


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