On Nov 3, 2021, at 7:34 PM, John Rose <john.r.r...@oracle.com<mailto:john.r.r...@oracle.com>> wrote:
There’s a bigger hiccup when you compare all that with good old int: int iv = 42; // “class int” is NOT a thing, but “class Integer” is assert iv.getClass() != int.class; // because int is not a class assert iv.getClass() == Integer.class; // ah, there’s the class! assert iv.getClass() == int.ref.class; // this works differently from Point assert ((Object)iv).getClass() == pr.getClass(); // this should be true also, right? And to finish out the combinations: int.ref ir = iv; // same object… now it’s on the heap, though, with a real live heap header assert ir.getClass() == Integer.class; // same class assert ir.getClass() == int.ref.class; // and this time it’s a ref-class (only for classic primitives) assert ir.getClass() != int.class; All this has some odd irregularities when you compare what Point does and what int does. And yet it’s probably the least-bad thing we can do. A bad response would be to follow the bad precedent of ir.getClass() == Integer.class off the cliff, and have pv.getClass() and pr.getClass() return Point.ref.class. That way, getClass() only returns a ref. Get it, see, getClass() can only return reference types. The rejoinder (which Brian made to me when I aired it) is devastating: Point.class is the class, not Point.ref.class, and the method is named “get-class”. I guess to rephrase this, I'll just say: yes, there are problems with int/Integer. But we shouldn't let that tail wag the dog when sorting out the language model. int/Integer is going to be a special case, no matter how we stack it. (On the other hand, we really like to look for analogies from int/Integer when sorting out the language model, and sometimes those are fruitful. But handle with care.)
