<div dir="ltr">I found today's discussion of giraffes and leashes that hold onto giraffes really useful. Sometimes we have the (flat papery) giraffe in hand, sometimes we have the leash. Whether we're directly holding it or holding the leash doesn't change the giraffe.<div><br></div><div>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.</div><div><br></div><div>Does the VAO model feel less forced if we're explicit about references being the difference?</div><div> - A value object can also be represented without an object reference, as primitives are today // (*)<br></div><div><br></div><div>--Dan</div><div><br></div><div>(And I don't think I've ever typed "giraffe" this many times before)</div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Wed, Aug 10, 2022 at 2:30 PM Brian Goetz <<a href="mailto:brian.goetz@oracle.com">brian.goetz@oracle.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<div>
And now to your other thread: <br>
<br>
<div>On 8/10/2022 1:38 PM, Kevin Bourrillion
wrote:<br>
</div>
<blockquote type="cite">
<div><br>
</div>
<div>The VANO model does a lot of "doubling down" on the
distinctions between objects and values, which does have a
certain "stuck in the past" feeling to it. A benefit is
"concreteness" and a feeling that "there is plenty of solid
ground under your feet that Valhalla is not pulling out from
under you". That feeling is important to me, particularly
because developers in the real world will regularly find
themselves going back and forth between pre-valhalla and
post-valhalla code for a very long time. A hazard is that it
equips developers to care more about that distinction that they
really should *moving forward*, particularly since the VM is a
cheating cheater. Essentially we're saying "for understanding,
you can lean on what you know about int-vs-Integer, but now
understand why the distinction will matter less and less to
you."</div>
<div><br>
</div>
<div>(John associates VANO with "boxes and arrows". I think that's
right and good? It seems called for because an <i>arrow</i> is
the thing that could be null instead.)</div>
<div><br>
</div>
<div>The VAO model does seem more forward-thinking. Why should we
invest in the question of when exactly objects "exist" or not
when those objects can't be programmatically distinguished from
each other anyway, nor from their corresponding values?</div>
<div><br>
</div>
<div>The eventual "final" presentation of value classes to users
(in the permanent documentation and the definitive seminal slide
presentations, and to *some* degree in the JLS itself) should
anchor on one model or the other. But these docs/presentations
might also want to say "and here's why you get to think of it
this other way when you want to". That may sound like trying to
have it both ways, but... I want to believe that as long as one
is subjugated to the other it would be fine. "Here's how little
is *really* changing; here's how your day-to-day modell gets to
evolve because of that".</div>
<div><br>
</div>
</blockquote>
<br>
The VAO model says:<br>
<br>
- classes have instances, which are objects<br>
- An object _reference_ can refer to any object, identity or value<br>
- A value object can also be represented directly, as primitives
are today // (*)<br>
- We've unified under "everything is an object", but added: not all
objects require references<br>
<br>
The uncomfortable part of this model is that while we are familiar
with the notion marked (*), because of primitives, we don't really
have a good name for it. So part of this is that there much
bumbling and fumfering around phrases like "represented directly"
and "bare" and other made-up words that we have to say "but but it's
just like what you know about primitives." <br>
<br>
The VANO model says:<br>
<br>
- classes have instances, but not all instances are objects. some
are values instead<br>
- Each value class V gets a special box class V.ref, which has a
single field of type V.val, like the boxes we know<br>
- The boxing and unboxing conversions, though, are super fast!
Because they're not burdened by identity preservation<br>
- We've unified under "everything is a class instance" and kept
"all objects require references", and the spirit (but not
performance) of boxes<br>
<br>
My intuition is that if we can come up with a better term for
"represented directly" that doesn't feel forced, the things we
dislike about VAO will be lessened and its unification under
"everything is an object" will win the day. <br>
<br>
<br>
</div>
</blockquote></div>