where are all the objects?

[Robbe Pincket]

Hi everyone

I've been watching (with a bit of confusion) what all the discussions were trying to accomplish. Now that I start to grasp some of the issues, I want to bring my thoughts.

My mind was still very much thinking with respect to the 3 buckets system, where stuff like "atomicity" was just a cool flag for the 3'rd bucket, but I've come to realize that I might need to leave that behind. My confusion started when people seemed to combine C.ref and C.val often, where in my mind they were quite different, one is "primitive like" while the other is a wrapper. 

On 22 Jul 2022, at 17:55 UTC, Brian Goetz wrote (I think this isn't on the list):

> [...] But I don’t think that there are instances of Complex.val and instances of Complex.ref; I think there are instances of *Complex*, and multiple ways to describe/store/access them.

On Fri Jul 22 19:02:23 UTC 2022, John Rose wrote:

> Circling back to the language design, it might seem odd that there are three ways to place an object but just two companion types. But this oddness goes away if you realize that C.val and C.ref are not placement directives. The choice between the two is a net-binary selection from a sizeable menu of “affordances” that the user might be expecting or disavowing at any given point in the code. (See my lists of “affordances” and “alternative affordances” in encapsulating-val.)
> The user is given this simplified switch to influence the JVM’s decisions about placement (and therefore representation). It is useful because the JVM can employ different implementation tactics depending on the differences between the user-visible contracts of C.ref and of C.val. In the choice of implementation tactics, the JVM has the final say.

These comments and a few others, made me realize I shouldn't keep these 2 variants so separate (at least with universal generics in mind). Things like "by value" and "by reference" come from languages like C, and its use in current Java to explain the difference between "objects" and "primitives" always rubbed me the wrong way. Mostly because of the fact that (after compiler magic) there isn't really a difference between "by ref" and "by val" for immutable data after the compiler did its magic.

Let's go back and think about `long`/`Long` and what their differences are now, and what they will be after universal generics are here:

Now:
1. `Long` implements stuff like `Number`, aka `Long` can extend classes and implement interfaces, and (references to) instances of `Long` can be assigned to variables of those supertypes. Values of `long` don't extend/implement anything.
2. Variables of the type `Long` are nullable, variables of `long` aren't.
3. Assigning stuff to a variable of `Long` is "atomic", meaning there are no unexpected values that appear in the variable. Variables of type `long` (currently) don't make this guarantee.
4. If you want to use generics, you need to use `Long`. You can't have an `ArrayList<long>`

Let's see how these change:
1. Once I can create an `ArrayList<long>` and I have a method of `<T implements Comparable<T>> void inPlaceQuickSort(List<T> list)` I expect to be able to pass my list into this method, meaning `long` must therefore implement `Comparable<long>`
2. This doesn't change, note however that now, `Optional<long>` is a thing too, and could easily replace most if not all remaining usages of `Long`
3. Idk what the plans are about making `long` atomic?
4. `ArrayList<long>` is now legal and has a neat property that it can no longer contain `null`. We can even replace usages of `ArrayList<Long>` with `ArrayList<Optional<long>>` to indicate we want the nullability/ability to be absent

Given that atomicity is the default for `.val`, the main difference between the `C.val` and `C.ref` is nullability, and people will use it as such. If you give them `T.flat`, people are gonna use it to mark fields that shouldn't be null, maybe even forgetting that they might now create new values when races occur.

While the fact whether a variable of a value type can be null is quite important for the JVM to improve performance, it feels weird that it is indicated by `.val` and `.ref` (although the later is implicit) or by `.flat` and `.box`.

Greetings
Robbe Pincket