And how does that differ from Point.class / Point.ref.class /
Point.class.noNotThatClassTheOtherClass() ?
I realize you're not necessarily asking that question in this thread,
but I want to walk through how I would respond to it anyway.
First here is what I already take to be true now:
The `java.lang.Class` type doesn't precisely represent a class, but an
erased type (let's forget about `void.class`). The relationship from
erased type to class is "1 to 0..1", so for any `j.l.Class` instance
that does have a related class, that instance can go ahead and
represent the class too (e.g. iterate over its methods). But the 8
"basic" primitive types don't have a class, and array types partly
pretend to be classes, but this is okay.
I think this is giving Class more credit than it might deserve, but
otherwise these arguments seem basically reasonable. Class started out
as 1:1 with .class files, but over time we realized "what about arrays",
"what about primitives", etc. It has been given too many jobs to do, so
it defies having a clear role, but we can try to avoid making it too
much worse.
* I assume the reason "the JVM type Qjava/lang/Double cannot be
encoded with a Class object" is because the distinction between
it and D is intentional implementation detail.
Worse :( The J and D carriers use two slots, so even if we
wanted to abstract over the primitive carriers, this is kind of a
dead end. The java/lang/Double class allows us to encode
List<double> with a class that carries a double but fits in one slot.
But... to be clear... it /is /also intentional implementation detail,
right? In the programming model a user can't care about the distinction?
Correct. The existence of the D carrier is an implementation detail of
the VM; if doubles were translated as LFakeDouble; the only thing the
user would notice is that things got slower and heaps got bigger.
