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.
Not to mention this circularity:
native inline class int implements BlahBlah {
int theValue; <-- oops
}
So to the extent these are written as .java files, some fakery is
inevitable.
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.
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.
Reactions?
I certainly understand your gut sense that trying to retcon Integer to
be something it was never meant to be will likely have some unexpected
consequences. But, its not like the alternative is great either.
Suppose we have `native inline class int { ... }`. So it gets a
reference projection, `int.ref`, and a inline widening conversion from
`int` to `int.ref`. And also, it already has a boxing conversion (with
the same semantics, and applicable in exactly the same places) to
`Integer`. Now what happens when someone does:
Object o = i;
There are gazillions of lines of code that hard-code the assumption that
this results in `Integer`. Every client of reflection is rife with this
assumption. So we're probably going to conclude that the boxing
conversion has to win over the widening conversion. And now every use
of primitives -- the most important inline types -- will be saddled with
accidental identity when they box. Which means that none of the boxing
cases we have now -- part of the motivation for doing Valhalla in the
first place -- will ever get better.
OK, that's existing code. What about new code? It gets worse! Some
libraries might use `List<int.ref>` (because they're better boxes), and
others might use `List<Integer>`. And they won't interop. And this
problem won't ever go away.
The move of saying `Integer` *is* `int.ref` makes these problems go
away. This seems too good to pass up preemptively.
