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.

Reply via email to