The fate of int, int.ref, and Integer
kevinb at google.com
Wed Jun 17 22:34:42 UTC 2020
Just want to record in *this* thread that the new thread "Evolving the
is easing some of my confusion and some of my concerns; anyone coming
across this should probably go there now.
On Sat, Jun 6, 2020 at 12:10 PM John Rose <john.r.rose at oracle.com> wrote:
> On Jun 5, 2020, at 5:43 AM, Brian Goetz <brian.goetz at oracle.com> wrote:
> The move of saying `Integer` *is* `int.ref` makes these problems go away.
> This seems too good to pass up preemptively.
> I agree. And this leads us into a maze of twisty passages.
> Full of uninsulated electrified wires and third rails to avoid.
> One tactic I like to get through the maze is to find a way to
> add some ad hoc polymorphism to Integer, while keeping it
> sealed up as a final class, like today. It seems to need to cover
> both good old identity objects (like new Integer(42)) and also
> new inline objects ((Integer)42, boxed as before, but via a new
> subtype relation). This means there are two object types
> floating around, identity-Integer and int, plus an API type,
> Integer-as-super. I think the notion of species (as a finer
> grained subdivision of types, under class) can be used to
> create the necessary distinctions, without introducing
> a lot of new types, and breaking reflection.
> In the spirit of brainstorming, here are more details on
> such a path, a that might lead us through the maze.
> Given this:
> int.ref id = new Integer(42); //identity object
> int.val x = id;
> int.val y = 42;
> int.ref z = y;
> …we could choose to arrange things so that all of
> x, y, z are inline objects (true “ints”), while id retains
> its special flavor. Also, Object.getClass could report
> Integer.class for *all* of those values (even y). This
> could be justified by revealing “int” as, not a class,
> but a *species* of Integer. So that Object.getSpecies
> would report the further details: For id it is the
> the version of Integer which holds identity (which
> doesn’t need a name I suppose) and for x/y/z it
> reports the species reflector for int.
> If we further use a muddied java.lang.Class to
> continue to represent non-classes like “int”,
> we have to double down on the idea of a “crass”,
> or “runtime class-like type”. In that case we can
> have getSpecies return a crass, and then:
> assert 42.getClass() == Integer.class;
> assert 42.getSpecies() == int.class;
> assert new Integer(42).getSpecies() == (something else);
Kevin Bourrillion | Java Librarian | Google, Inc. | kevinb at google.com
More information about the valhalla-spec-observers