<html>
  <head>
    <meta http-equiv="Content-Type" content="text/html; charset=utf-8">
  </head>
  <body text="#000000" bgcolor="#FFFFFF">
    <br>
    <div class="moz-cite-prefix"><br>
    </div>
    <blockquote type="cite"
      cite="mid:7B7410AB-AE95-4486-88F7-BA428BDFC859@d-d.me">
      <meta http-equiv="Content-Type" content="text/html; charset=utf-8">
      <div style="font-family:sans-serif">
        <div style="white-space:normal">
          <p dir="auto">This is a very good and a pleasant read, thank
            you!<br>
            Especially nice to see a clear definition of design
            requirements.<br>
            I have several follow up questions: </p>
          <ul>
            <li>
              <p dir="auto">do you envision data classes as Java
                language feature or JVM platform feature?<br>
                Are additional features such as externalization
                implemented by runtime magic or by<br>
                Bytecode generated by compiler ahead of time?</p>
            </li>
          </ul>
        </div>
      </div>
    </blockquote>
    <br>
    We will likely do the same thing we did with Lambda, where we
    provide JDK runtime for implementing the Object methods using indy. 
    In our prototype, we expose invokedynamic bootstraps that implement
    equals, hashCode, and toString, which take as their static arguments
    method handles for fetching the fields (and in the case of toString,
    also field names), like this:<br>
    <br>
        public static CallSite makeEquals(MethodHandles.Lookup lookup,
    String invName, MethodType invType,<br>
                                          Class<? extends
    DataClass> dataClass, MethodHandle... getters) throws Throwable {<br>
            return new ConstantCallSite(makeEquals(dataClass,
    List.of(getters)));<br>
        }<br>
    <br>
    The static compiler, in the body of equals(), just generates a a
    single invokedynamic instruction whose bootstrap is this method,
    whose static arguments describe this class, and whose dynamic
    arguments are those of equals().  Other language compilers could do
    the same.  <br>
    <br>
    <blockquote type="cite"
      cite="mid:7B7410AB-AE95-4486-88F7-BA428BDFC859@d-d.me">
      <div style="font-family:sans-serif">
        <div style="white-space:normal">
          <ul>
            <li>
              <p dir="auto">requirements stipulated in section “Towards
                requirements for data classes” feel like they <br>
                should not only impose limits on the dataclass, but also
                types of fields the data class could contain. For
                example:<br>
                <code style="background-color:#F7F7F7;
                  border-radius:3px; margin:0; padding:0 0.4em"
                  bgcolor="#F7F7F7">For any instance c of C,
                  ctor(dtor(c)) equals c, according to the equals()
                  contract for C, <br>
                  and further, that the composition ctor(dtor(x)) is an
                  identity on the codomain of ctor.</code><br>
                this assumes that equals on fields is also well-behaved.<br>
                While in perfect world I’d prefer to limit data-classes
                to only have well-behaved fields, <br>
                I see that this may be infeasible. I think it is still
                worth spelling that requirements&definitions<br>
                of transparent carrier are conditional on
                well-behaveness of fields + formally defining this
                well-behaveness. </p>
            </li>
          </ul>
        </div>
      </div>
    </blockquote>
    <br>
    Yeah, I'm not really sure what more we can do here, but I agree that
    this is a place where our requirements could be implicitly
    undermined.  Any suggestions?<br>
    <br>
    <blockquote type="cite"
      cite="mid:7B7410AB-AE95-4486-88F7-BA428BDFC859@d-d.me">
      <div style="font-family:sans-serif">
        <div style="white-space:normal">
          <ul>
            <li>
              <p dir="auto">while I agree that names are meaningful in
                Java, it would be nice to be able to generically inspect
                and\or <br>
                deconstruct arbitrary data-class as if it was a tuple.
                This will allow generic handling of data-classes<br>
                when it makes sense. Do you have ideas in this area?</p>
            </li>
          </ul>
        </div>
      </div>
    </blockquote>
    <br>
    We will generate deconstructor patterns for these things, of course,
    which can be statically invoked by name (case Point(var x, var y)). 
    And deconstructor patterns can be invoked reflectively, but I know
    that's also not what you mean (though may be good enough for
    frameworks).  I think what you mean is something more like "data
    interfaces", where a data class can "implement" a more abstract
    deconstructor?  <br>
    <br>
    <blockquote type="cite"
      cite="mid:7B7410AB-AE95-4486-88F7-BA428BDFC859@d-d.me">
      <div style="font-family:sans-serif">
        <div style="white-space:normal">
          <ul>
            <li>
              <p dir="auto">Mutability: I agree that enforcing complete
                immutability is impractical. <br>
                But I’m curios if you’re current thinking is to limit
                mutability to class itself(as if setters were private)<br>
                or to allow data classes to be mutated externally(as if
                setters were public).<br>
                My feeling that the former route is nice because it
                allows data class authors <br>
                to expose mutability only if only they want to. What was
                your thinking?</p>
            </li>
          </ul>
        </div>
      </div>
    </blockquote>
    <br>
    The most restrictive position is: fields are always final and are
    always publicly readable (either because the fields themselves are
    public, or we provide public read accessors.)  This is a principled
    position, but is probably impractical.  <br>
    <br>
    The likely practical compromise is:<br>
     - fields are final by default, but can be declared "unfinal"<br>
     - fields are private by default, but can be declared public<br>
     - you get public read accessors, no matter what<br>
    <br>
    So if you do nothing, you get final and readable, which is a
    reasonable default.  If you opt into mutability, fields are still
    private, and you have the option to expose mutative methods, or
    not.  If you opt into mutability and public-ness, people can do
    whatever they want.  <br>
    <br>
    <br>
    <blockquote type="cite"
      cite="mid:7B7410AB-AE95-4486-88F7-BA428BDFC859@d-d.me">
      <div style="font-family:sans-serif">
        <div style="white-space:normal">
          <ul>
            <li>
              <blockquote style="border-left:2px solid #777; color:#777;
                margin:0 0 5px; padding-left:5px">
                <p dir="auto">The arguments to the extends Base() clause
                  is a list of names of state components of Sub … <br>
                  must be a prefix of the state description of Sub,</p>
              </blockquote>
              <p dir="auto">Curiosity: why do you need it to be a
                prefix? It didn’t understand it from the writeup.<br>
              </p>
            </li>
          </ul>
        </div>
      </div>
    </blockquote>
    <br>
    Essentially, this is "nominal width subtyping".<br>
    <br>
    This isn't essential, though I think this requirement is useful to
    nudge people away from mistaken ideas about extension; the degrees
    of freedom it removes are relatively weak in expressiveness, but
    still make it possible for users to confuse themselves, such as when
    Foo(int x, int y) is declared to extend Bar(int y, int x).  <br>
    <br>
    <blockquote type="cite"
      cite="mid:7B7410AB-AE95-4486-88F7-BA428BDFC859@d-d.me">
      <div style="font-family:sans-serif">
        <div style="white-space:normal">
          <ul>
            <li>
              <p dir="auto">
                I feel like this might be limiting: if you’re working on
                abstract ADTs, you are likely to work on<br>
                Very abstract entities, where convenient order of
                arguments is not yet clear. When ADTs become less
                abstract<br>
                in different subtypes it will become clear and can be
                different in different branches of inheritance
                hierarchy.</p>
            </li>
          </ul>
        </div>
      </div>
    </blockquote>
    <br>
    Please share examples!  <br>
    <br>
    Cheers,<br>
    -Brian<br>
    <br>
  </body>
</html>