On Nov 2, 2021, at 3:44 PM, Kevin Bourrillion
<kev...@google.com<mailto:kev...@google.com>> wrote:
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).
It seems like `Complex.class` (as opposed to `Complex.ref.class`) would never
be returned by `Object.getClass()` in any other condition than when you could
have just written `Complex.class` anyway.
Actually, that makes me start to wonder if `getClass()` should be another
method like `notify` that simply doesn't make sense to call on value types.
(But we still need the two distinct Class instances per class anyway.)
Yep, you hit on a tricky spot there. One part of the problem
is that getClass, specifically and uniquely, has a special relation
the the primitive types which is coupled to the typing of
class literals like int.class (which is Class<Integer> not Class<int>).
Also, Integer is a class, and Complex is a class, but they have
different “tilts”: Integer is (kinda sorta) int.ref but Complex
is not Complex.ref, and the mirrors reflect this difference.
Sorting this out seems to be an overconstrained problem.
As you say, we have not yet applied “.getClass” to any
non-ref type, yet, but we will certainly do so, and that’s
when the fun begins.
Also, trying to retype int.class as Class<int> is a related
part of the fun.
In the end, however nicely we “heal the rift” between
good old int and his new friend Complex, there will
surely be some scars on good old int from his time
marooned (with just a few friends) in primitive-land.
(My current mental metaphor for the isolation of int
is Gilligan, who had about the same number of
unfortunate island-mates as int does.)
