
<!DOCTYPE html><html><head>

<meta http-equiv="Content-Type" content="text/html; charset=utf-8">

  </head>

  <body>

    <span style="white-space: pre-wrap">

</span>

    <blockquote type="cite" cite="mid:AF2B08F7-6F7F-41D2-B545-8F2FBD92BB3A@oracle.com">

      <pre class="moz-quote-pre" wrap="">

But I've come around to the idea that a simple "all classes are identity by default" rule is good, and that the binary compatibility commitment associated with "value" (e.g., the class will never add a mutable field) is better stated explicitly.</pre>

    </blockquote>

    I agree with this - it makes the mental map so much easier!<br>

    <blockquote type="cite" cite="mid:AF2B08F7-6F7F-41D2-B545-8F2FBD92BB3A@oracle.com">

      <pre class="moz-quote-pre" wrap="">


</pre>

      <blockquote type="cite">

        <pre class="moz-quote-pre" wrap="">(For awhile, I was considering keeping around the 'identity' keyword, just for the purpose of interfaces. But, eh, nobody is going to use it.)

</pre>

      </blockquote>

      <pre class="moz-quote-pre" wrap="">

One problem I noticed with a two-state interfaces approach is that interfaces need to be "value interfaces" by default, but we probably don't want to allow a "value interface" to extend an "identity interface", because in this iteration 'value' is an assertion about supertypes. (In contrast to the 3-state case, where it was fine to allow an "unconstrained interface" to extend an "identity interface".)</pre>

    </blockquote>

    <p>Yep, allowing a class to implement a mix of value and non-value

      interface seems messy - saying that all interfaces are "value"

      seems much better.</p>

    <p>Maurizio<br>

    </p>

  </body>

</html>