<html>
  <head>
    <meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
  </head>
  <body text="#000000" bgcolor="#FFFFFF">
    <tt>When we have sealed classes and records, it will be practical
      and sensible to declare entire related hierarchies together: <br>
      <br>
      -- Shape.java<br>
          sealed interface Shape { }<br>
      <br>
          record Circle(Point center, int radius) extends Shape;<br>
          record Square(Point corner, int length) extends Shape;<br>
      --<br>
      <br>
      Not only is it inconvenient for the writer to require each get
      their own source file, but more importantly, it is bad for the
      reader -- separating these declarations makes it hard to see what
      is a group of related entities.  (Imagine if we required a
      separate source file for each enum constant; it would be much
      harder to see the structure of an enum.)  So we want to encourage
      this sort of co-declaration.  <br>
      <br>
      It is an easy rejoinder to say "Then just declare them as nested
      in the Shape, and use static imports to clean up the use-site
      damage from that."  But this is a bad answer, because, as Remi and
      Maurizio point out, this affects _the structure of your public
      API_.  But that means we're putting users in a place where they
      get to pick two of the following three features:<br>
      <br>
       - Use sealing<br>
       - Declare a sealed hierarchy with its source together<br>
       - Declare a flat API<br>
      <br>
      I've seen API style guides that forbid the use of public nested
      classes.  And while I don't personally program this way, I think
      its a not-ridiculous house style.  But then people in this
      situation have to write in a less readable, less maintainable
      way.  <br>
      <br>
      So, my "for whatever reason" means: People should get to choose
      the shape of their exported APIs (and flat is a valid shape
      preference), and not be forced into a particular shape because
      they want to use sealing.  The API shape above -- a sum of records
      -- is one we should encourage, not discourage.<br>
      <br>
    </tt><br>
    <br>
    <div class="moz-cite-prefix">On 11/26/2018 2:43 PM, Kevin
      Bourrillion wrote:<br>
    </div>
    <blockquote type="cite"
cite="mid:CAGKkBkva4+Q_JnEw59srgCKhUH0Zn3as9PkJ9J1rxu=kBpHehA@mail.gmail.com">
      <meta http-equiv="content-type" content="text/html; charset=UTF-8">
      <div dir="ltr">Sorry for delay. Can we unpack the "for whatever
        reason" part?  For what reason?
        <div><br>
        </div>
        <div>Unsurprisingly to anyone, we actually hard-ban this
          practice here. Multiple top-level classes per file just make
          code harder to find; what are the advantages?</div>
      </div>
      <br>
      <div class="gmail_quote">
        <div dir="ltr">On Mon, Nov 12, 2018 at 8:35 AM Brian Goetz <<a
            href="mailto:brian.goetz@oracle.com" moz-do-not-send="true">brian.goetz@oracle.com</a>>
          wrote:<br>
        </div>
        <blockquote class="gmail_quote" style="margin:0 0 0
          .8ex;border-left:1px #ccc solid;padding-left:1ex">
          <div style="word-wrap:break-word">This was received through
            amber-spec-comments.  
            <div><br>
            </div>
            <div>I agree with the general sentiment, especially for
              sealed types, where we want to define an entire sealed
              type hierarchy in a single compilation unit (but for
              whatever reason, prefer not to nest the subtypes in the
              super type.)  There are some details to be worked out
              (e.g., use of the SourceFile attribute by tools).  <br>
              <div><br>
                <blockquote type="cite">
                  <div>Begin forwarded message:</div>
                  <br
                    class="m_6495034347966923286Apple-interchange-newline">
                  <div
style="margin-top:0px;margin-right:0px;margin-bottom:0px;margin-left:0px"><span
                      style="font-family:-webkit-system-font,Helvetica
                      Neue,Helvetica,sans-serif;color:rgba(0,0,0,1.0)"><b>From:
                      </b></span><span
                      style="font-family:-webkit-system-font,Helvetica
                      Neue,Helvetica,sans-serif">Francois Green <<a
                        href="mailto:francois.green@gmail.com"
                        target="_blank" moz-do-not-send="true">francois.green@gmail.com</a>><br>
                    </span></div>
                  <div
style="margin-top:0px;margin-right:0px;margin-bottom:0px;margin-left:0px"><span
                      style="font-family:-webkit-system-font,Helvetica
                      Neue,Helvetica,sans-serif;color:rgba(0,0,0,1.0)"><b>Subject:
                      </b></span><span
                      style="font-family:-webkit-system-font,Helvetica
                      Neue,Helvetica,sans-serif"><b>Lifting the
                        restriction on the number of public classes per
                        file</b><br>
                    </span></div>
                  <div
style="margin-top:0px;margin-right:0px;margin-bottom:0px;margin-left:0px"><span
                      style="font-family:-webkit-system-font,Helvetica
                      Neue,Helvetica,sans-serif;color:rgba(0,0,0,1.0)"><b>Date:
                      </b></span><span
                      style="font-family:-webkit-system-font,Helvetica
                      Neue,Helvetica,sans-serif">November 11, 2018 at
                      10:09:06 PM GMT+1<br>
                    </span></div>
                  <div
style="margin-top:0px;margin-right:0px;margin-bottom:0px;margin-left:0px"><span
                      style="font-family:-webkit-system-font,Helvetica
                      Neue,Helvetica,sans-serif;color:rgba(0,0,0,1.0)"><b>To:
                      </b></span><span
                      style="font-family:-webkit-system-font,Helvetica
                      Neue,Helvetica,sans-serif"><a
                        href="mailto:amber-spec-comments@openjdk.java.net"
                        target="_blank" moz-do-not-send="true">amber-spec-comments@openjdk.java.net</a><br>
                    </span></div>
                  <br>
                  <div>
                    <div>In the face of the changes in code style that
                      records will bring about, has<br>
                      there been renewed discussion about lifting the
                      restriction?<br>
                      <br>
                         public interface Blue;<br>
                         public record IKB() implements Blue;<br>
                         public record Azure() implements Blue;<br>
                         public record Royal() implements Blue;<br>
                      <br>
                      Having to place each line in the code above in its
                      own file seems harsh.<br>
                    </div>
                  </div>
                </blockquote>
              </div>
              <br>
            </div>
          </div>
        </blockquote>
      </div>
      <br clear="all">
      <div><br>
      </div>
      -- <br>
      <div dir="ltr" class="gmail_signature"
        data-smartmail="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">kevinb@google.com</a></span></div>
                </div>
              </div>
            </div>
          </div>
        </div>
      </div>
    </blockquote>
    <br>
  </body>
</html>