<div dir="ltr">I thought we had a good discussion this morning. Some random followups:<div><br></div><div>I like the concept of identity as akin to an extra field that only identity classes have, very much. It should feel like an "extra" feature, and purely behavioral in nature. That means I like to untie identity from addressability; push back on the idea that a reference encodes the object's identity in any way. It's instead some opaque "location" and we have no further expectations about it.</div><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></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Tue, Jul 26, 2022 at 3:42 PM Dan Smith <<a href="mailto:daniel.smith@oracle.com">daniel.smith@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 style="overflow-wrap: break-word;">
<div>
<blockquote type="cite">
<div>On Jul 22, 2022, at 9:04 AM, Kevin Bourrillion <<a href="mailto:kevinb@google.com" target="_blank">kevinb@google.com</a>> wrote:</div>
<br>
<div><span style="font-family:Helvetica;font-size:12px;font-style:normal;font-variant-caps:normal;font-weight:400;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;text-decoration:none;float:none;display:inline">Note
 that *some* decisions which produce strong initial antipathy in the minds of users will actually become good teachable moments! "Here's why the reaction you had was tied to old assumptions that we are intentionally leaving behind for these good reasons." Even
 a user who doesn't<span> </span></span><i style="font-family:Helvetica;font-size:12px;font-variant-caps:normal;font-weight:400;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;text-decoration:none">agree</i><span style="font-family:Helvetica;font-size:12px;font-style:normal;font-variant-caps:normal;font-weight:400;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;text-decoration:none;float:none;display:inline"> with
 the decision can still hang their </span><i style="font-family:Helvetica;font-size:12px;font-variant-caps:normal;font-weight:400;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;text-decoration:none">learning</i><span style="font-family:Helvetica;font-size:12px;font-style:normal;font-variant-caps:normal;font-weight:400;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;text-decoration:none;float:none;display:inline"> onto
 this. In fact I think some of the *best* teachable moments will be like that.</span></div>
</blockquote>
</div>
<br>
<div>This seems like a really good piece of wisdom to hold on to in all of our terminology/model discussions. Unintuitive != bad. Thanks!</div>
</div>

</blockquote></div><br clear="all"><div><br></div>-- <br><div dir="ltr" class="gmail_signature"><div dir="ltr"><div><div dir="ltr"><div><div dir="ltr"><div style="line-height:1.5em;padding-top:10px;margin-top:10px;color:rgb(85,85,85);font-family:sans-serif"><span style="border-width:2px 0px 0px;border-style:solid;border-color:rgb(213,15,37);padding-top:2px;margin-top:2px">Kevin Bourrillion |</span><span style="border-width:2px 0px 0px;border-style:solid;border-color:rgb(51,105,232);padding-top:2px;margin-top:2px"> Java Librarian |</span><span style="border-width:2px 0px 0px;border-style:solid;border-color:rgb(0,153,57);padding-top:2px;margin-top:2px"> Google, Inc. |</span><span style="border-width:2px 0px 0px;border-style:solid;border-color:rgb(238,178,17);padding-top:2px;margin-top:2px"> <a href="mailto:kevinb@google.com" target="_blank">kevinb@google.com</a></span></div></div></div></div></div></div></div>