On Thu, Feb 10, 2022 at 4:25 AM Brian Goetz <brian.go...@oracle.com> wrote:
I think this is a useful exercise anyway, though; we have stumbled over > type-vs-class in a lot of places already with respect to B3, and int has > similar problems; most uses of `int` are types, but there's also > `int.class`, which means ... something. What exactly? > We *would* normally get 2 types called `Integer` and `Integer.ref`, but INSERT MAGIC HERE we make them come out as `int` and `Integer` instead for compatibility. So `int.class` is just what *would* have been `Integer.class` normally. The reason every other appearance of `int` is a type is that the other forms of "class usage, not type usage" listed on page 179 of JLS v17 ... all just don't happen to really apply. (Actually it seems like that list will have to be broken up now, huh?) > 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. For starters this seems friendly to the arrival of Point. The relationship becomes "1..2 to 0..1", which could break some program assumptions, but it *basically* keeps working the same. I assume that Point.ref.class will have a modified name in some way, and some boolean method will address the distinction between the two, but they'll otherwise be identical. They'll even be tied together; e.g. use reflection to modify a field in one, it's magically changed on the other too. The mental model here is "one class, two Classes" and while that's a bit unfortunate, again, Class already doesn't really mean the same thing as class as it is. * 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? -- Kevin Bourrillion | Java Librarian | Google, Inc. | kev...@google.com
