On 10 Aug 2022, at 12:34, Brian Goetz wrote:
On 8/10/2022 3:17 PM, Dan Heidinga wrote:
Which fits with the VAO model. Object references are clearly our
giraffe leashes but that doesn't give us a good word for the
flattened papery giraffe itself. The challenge here is we're not
describing a property of the thing, we're describing the lack of
something (the leash or reference). Add to this the VM doesn't
provide guarantees about the storage for the non-reference case -
it's all VM discretion on whether to flatten or not - so
accurate terms feel like weasel words.
Does the VAO model feel less forced if we're explicit about
references being the difference?
- A value object can also be represented without an object
reference, as primitives are today // (*)
This is actually the new weirdness --
that you have a choice about how to handle a value object.
Previously we had two kinds of things: primitives (direct values) and
object references (which can be null, or can have an object at the end
of them, but you can't touch the object, only the reference.) Now we
still have two kinds of values: value objects, and object references
--
but object references can also refer to value objects! This is the
weird part; that value objects have two separate placements /
representations / interaction modes. We got away before without a
notion of "bare object" because the only way you could touch a
primitive is directly, and the only way you could touch an object is
through a reference. But now some objects can be touched directly,
*or* through a reference.
C programmers would say "Duh, that's just X vs X*", but we want to
blur the difference, so we don't distinguish between `x.a` and `x->a`
as we do in C.
Brainstorming on terms....we haven't tried "unboxed".
- A Point.ref is a reference to a Point object
- A Point.val is an unboxed Point object
The issue with many of these formulations (like “unboxed Point”) is
that it makes it sound like the Point object has a funny decoration on
it that makes it be unboxed. But what we want to say (I think) is that
it is unburdened by any such decoration. That’s why I like a “just
the facts” Point: “pure Point” or “bare Point” or “simple
Point” or “unadorned Point”. Or maybe, suggesting the lack of an
intermediary, “immediate Point” or “direct Point”.
This fits into the "reference as default" model, but it suggests that
Point.val are *not* objects, they are the "scooped out filling" of an
object. So I guess this is more of a VANO term. Oh well.
Yeah; it seems to damage the integrity (simplicity, purity) of the Point
to say, “oh that’s a spilled point”. (Spilled = unboxed.)
Is there any mileage in splitting "reference" instead of object? Like,
a "lightweight reference" (a short leash), which doesn't support
polymorphism or null? Then a Point.val is a "lightweight reference"
to a Point?
I think there is some mileage there for specifications, if not for
teaching and learning. That’s why I suggested “value arrows” in
my previous. Those are the same as your “short leash”.
The VAO term we are looking for might be more like "grab the giraffe
by the collar, rather than by the leash" :)
Yes, the two-heap model suggests we could pretend that all objects
require leashes of some sort (chopsticks), but there are short ones and
long ones with somewhat differing operational semantics (especially for
`==`/`acmp`).
And then, *as an optimization* but not in the specification, a
short-leash giraffe can climb right up into your lap (if the VM lets
it). You know you’ll like it, since you always preferred your ints
and bytes close at hand.
