[External] : Re: Consolidating the user model

[Dan Smith]

On Nov 3, 2021, at 7:34 PM, John Rose <john.r.rose at oracle.com<mailto:john.r.rose at 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.)