On Nov 3, 2021, at 11:23 AM, Kevin Bourrillion <kev...@google.com<mailto:kev...@google.com>> wrote:
On Wed, Nov 3, 2021 at 9:02 AM John Rose <john.r.r...@oracle.com<mailto:john.r.r...@oracle.com>> wrote: > One way to thicken this thin argument is to say that Point is not really a > class. > It’s a primitive. Then it still has a value-set inclusion relation to > Object, but it’s > not a sub-class of Object. It is a value-set subtype. I would spin it like this: `Point` absolutely is a class. But its instances are values (like ints and references are, but compound), and values are still not objects. We've said at times we want to "make everything an object", but I think the unification users really care about is everything being a class instance. I think this fits neatly with the current design: `Point` has no supertypes*, not even `Object`, but `Point.ref` does. (*I mean "supertype" in the polymorphic sense, not the "has a conversion" sense or the "can inherit" sense. I don't know what the word is really supposed to mean. :-)) These sorts of explanations make me uncomfortable—that a Point stored in a reference isn't really a Point anymore, but a "box" or something like that. The problem is that you want to say that the Point gets converted to some other thing, yet that other thing: - is == to the original - provides the exact same API as the original - has the exact same behaviors as the original - works exactly like a class declared with original class's declaration If you're telling people that when you assign a Point to type Object, they now have something other than a Point, they're going to want to *see* that somehow. And of course they can't, because the box is a fiction. The reference vs. value story that we developed to address these problems (and problems that arise when you *do* let people "see" a real box) carries the right intuitions: you can handle a Point by value or by reference, but either way it's the exact same object, so of course everything you do with it will work the same.
