[External] : Re: Consolidating the user model

[Kevin Bourrillion]

On Tue, Nov 2, 2021 at 4:53 PM Brian Goetz <brian.goetz at oracle.com> wrote:

## Reflection
>>
>> Earlier designs all included some non-intuitive behavior around
>> reflection.
>> What we'd like to do is align the user-visible types with reflection
>> literals
>> with descriptors, following the invariant that
>>
>>      new X().getClass() == X.class
>>
>
> Seems like part of the goal would be making it fit naturally with the
> current int/Integer relationship (of course, `42.getClass()` is uncommitted
> to any precedent).
>
>
> There's a nasty tension here.  On the one hand, for B3 classes, it makes
> sense for b3.getClass() to yield the val mirror, but int.getClass()
> historically corresponds to the ref mirror (Object o = 3; o.getClass() ==
> Integer.class.)
>

I'm confused at why there's any concern here. `anInt.getClass()` has never
existed, so it can do anything. The code snippet you show is obviously
boxing so of course the class is that of the box.


You could argue that it doesn't make sense on the values, but surely it
> makes sense on their boxes.  But its a thin argument, since classes extend
> Object, and we want to treat values as objects (without appealing to
> boxing) for purposes of invoking methods, accessing fields, etc.  So
> getClass() shouldn't be different.
>

Sorry for this: I'm not trying to push values-aren't-objects relentlessly
in multiple threads, but I think what you said is a little off, and worth
pushing back on no matter which model is the one we ship.

"Invoking methods, accessing fields" really seem a lot like things you can
do with *class instances*, and who cares if it's an "object" or not.
Consider two points: we call them "instance methods", not "object methods",
and where do they come from? From a class. This seems to me to be at the
heart of what classes and class instances are about. I don't find a reason
to utter the word "object" while talking about this. When do I, then?
Well....

You say "we want to treat values as objects for purposes of invoking
methods." But I'm not sure you really want that. :-) *Objects* have dynamic
dispatch, so it has to dereference and check the dynamic type and
re-resolve what method to actually call. Values have none of that junk,
just call the method. RIght? I think that's significant. What I think you
mean (?) is that invoking methods needs to *work* for all kinds of class
instances. But it works a bit *differently* for values vs. objects (in my
parlance; in your current parlance, that's "it works differently for values
vs. objects-except-values").

(If preparing to respond that methods on a static type that's final don't
have dynamic dispatch either, meh, that's more simply understood as "of
course you don't actually query when you already know the answer; that's
just optimization". Whereas with the value type, the idea of this querying
at all isn't even a thing.)

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