On Jun 4, 2020, at 7:00 PM, Kevin Bourrillion <[email protected]> wrote: > > Hello friends, > > A couple thoughts on the fate of the primitives and wrappers. > > First, on nomenclature, I think the most useful definitions of what it means > to be an "inline type" are those that reveal the primitives to already be > inline types. Java's always had them, but it hasn't had user-defined inline > types, because it hasn't had inline classes (and classes are how we > user-define types). That's clean, and it's not even a retcon.
+1 We have tried to keep “works like an int” as a goal. I don’t think we’ve compromised too much away from that; I think your formula works, except for the technical fact that “inline” is always followed by “class”. > Also on nomenclature, I want to avoid phrases like "you can expand the set of > primitives"; no, I still think that "primitives" should always apply to the > eight predefined, irreducible inline types. User-defined inline types are > always composite (how could they not be?). Yes. But: I expect that JVMs will sometimes secretly define things that look like inline classes but in fact are physically atomic (except bitwise of course). Vectors in AVX are like this: They go in one register, not many. I expect such things to be hidden from the end user, in places like jdk.internal.types, and wrapped in ordinary inline wrapper classes for public consumption. > > I approve of the idea of writing int.java etc. files in order to add methods > to `int`, and add interfaces to `int.ref`. It is fine if these files are > essentially "fake" (they don't actually bring the primitives into existence > as other classes do). I think attempts to try to make them look "real" would > mean letting them do things other inline types can't and it definitely > wouldn't seem worth it to me. Yep. We are a long way from doing so, I think. We might like some kind of Haskell-flavored fu that lets us relate those things to their operators. At least, I’d like to know something about that road ahead, before committing to the initial contents of int.java. > What I would explain is "In Java <X, `int` was not a class; it didn't need to > be because it had no members. Now in Java >=X that it has members and > implements `Comparable`, it is a class for that reason, but the type itself > is still predefined with or without that class.” I think people would not be satisfied with such an explanation, until we can explain why 42.toString() does or doesn’t work, and how 42 < 43 connects to a call to Comparable.compareTo, and (worst of all) how 1.0 == 1.0 connects to the Java == operator on classes and/or Comparable.compareTo (pick one). So we’re pretty far from making int into a class, or from writing int.java. But, yes, we can say that primitives are (in some sense to be defined or hand waved away) “inline types”. > > (wart: yeah, arrays have no class, yet sure seem to have members `length` and > `clone` anyway. oh well.) > > I also approve of giving the new `int` class everything it needs so that the > `Integer` class becomes obsolete; that is, there would no longer be any good > reason to use it except when forced by legacy code. (Of course, anything that > wants to depend on identity or locking of such an object I will just declare > to be legacy code, so it works!) Really though, don't bring `getInteger` over > when you do. This is a maze of twisty passages. I agree there’s are ways through it. We want to choose a way through that doesn’t leave us disgusted with ourselves in the morning. > However, I am highly skeptical of attempts to do anything else beyond that. > I've seen, at least, the allusions to some kind of aliasing between `int.ref` > and `Integer`. That seems unnecessary to me, and more to the point, I feel > that it can only make things more confusing to users; that in fact it will > cause a large share of all the confusion they do feel. So wait, what IS the > wrapper class then? What IS this reference projection then? I see no benefit > to blurring that line, at this point. Interesting. I don’t have a strong feeling, but I *do* hope that we could define by fiat that Integer is the ref-projection of int, sooner rather than later. You are prompting me to re-examine this idea, and see what it might buy us. At the very least, I’d like to be say List<int.ref> instead of List<Integer> and get away with it. This is touching on exactly what we can do (short and long term) with generics, which is an open question. Are you saying that it would be risky to declare that int.ref == Integer, because it would make it harder to get rid of Integer? Isn’t it going to be impossible anyway to get rid of Integer? I think the problem is mainly to make Integer as palatable as possible in the future, perhaps deprecating some of the oldest cruft, and (at least conceptually) attributing the useful parts to int, even before we venture to write int.java. My $0.02. Thanks for raising the question. — John
