<html><head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
  </head>
  <body>
    <font size="4"><font face="monospace">All fair.  So what this comes
        down to is whether the uniformity of "ref types are all the
        same" is one that we want to have trumped by "non-atomic classes
        tear in all conditions."  Truly a battle for conceptual
        supremacy.</font></font><br>
    <br>
    <div class="moz-cite-prefix">On 6/15/2022 2:10 PM, Kevin Bourrillion
      wrote:<br>
    </div>
    <blockquote type="cite" cite="mid:CAGKkBktygkVywkd0XQmPGhMpix_8=Gc34Sqy1oe0KHvSV17Pow@mail.gmail.com">
      
      <div dir="ltr">
        <div dir="ltr">On Wed, Jun 15, 2022 at 10:51 AM Brian Goetz <<a href="mailto:brian.goetz@oracle.com" moz-do-not-send="true" class="moz-txt-link-freetext">brian.goetz@oracle.com</a>>
          wrote:<br>
        </div>
        <div class="gmail_quote">
          <div dir="ltr" class="gmail_attr"><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> - If we spelled .val as !, then switching from P[] to
              P![] not only prohibits null elements, but changes the
              layout and _introduces tearing_.  Hiding tearability
              behind "non-null" is likely to be a lifetime subscription
              to Astonishment Digest, since 99.9999 out of 100 Java
              developers will not be able to say "non-null, oh, that
              also means I sacrifice atomicity." </div>
          </blockquote>
          <div><br>
          </div>
          <div>Well, that's what you opted into when you... wait a
            minute...</div>
          <div><br>
          </div>
          <div> </div>
          <blockquote class="gmail_quote" style="margin:0px 0px 0px
            0.8ex;border-left:1px solid
            rgb(204,204,204);padding-left:1ex">
            <div>The link you probably want to attack is this last one,
              where you are likely to say "well, that's what you opted
              into when you said `non-atomic`; you just happen to get
              atomicity for free with references, but that's a bonus." <br>
            </div>
          </blockquote>
          <div><br>
          </div>
          <div>Your Kevin's Brain Emulator has gotten pretty decent over
            time... check whether the next things it said were these
            (probably so):</div>
          <div><br>
          </div>
          <div>A good clean Basic Conceptual Model For Novices is
            allowed to have a bunch of asterisks, of the form "well, in
            $circumstance, this will be revealed to be totally false",
            and that's not always a strike against the model. How do we
            discern the difference between a good asterisk and a bad
            one? How common the circumstance; how recognizable as <i>being</i> a
            special circumstance; how disproportionate a truth
            discrepancy we're talking about; etc.</div>
          <div><br>
          </div>
          <div>I know I've said this before. If I'm in a class being
            taught how this stuff works, and the teacher says "Now
            unsafe concurrent code can break this in horrible ways, and
            in $otherClass you will learn what's really going on in the
            presence of data races" ... I feel fully satisfied by that.
            I know I won't get away with playing fast and loose with The
            Concurrency Rules; I'm not advanced enough and might never
            be. (Many people aren't but <i>don't </i>know it, and
            therein lies the problem, but do we really have much power
            to protect such people from themselves?)</div>
          <div><br>
          </div>
          <div>I could be wrong, but I suspect this kind of viewpoint
            might be more common and respected in the wider world than
            it is among the rarefied kind of individuals who join expert
            groups, no offense to anyone here meant. You're always going
            to see all the details, and you're always going to <i>want</i> to
            see all the details. The general public just hopes the
            details stay out of their way. When they don't, they have a
            bad day, but it doesn't mean they were better served by a
            complex model that tried to account for everything.</div>
          <div><br>
          </div>
          <div><br>
          </div>
        </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" moz-do-not-send="true" class="moz-txt-link-freetext">kevinb@google.com</a></span></div>
                  </div>
                </div>
              </div>
            </div>
          </div>
        </div>
      </div>
    </blockquote>
    <br>
  </body>
</html>