<html><head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
  </head>
  <body>
    <br>
    <blockquote type="cite" cite="mid:CAJq4Gi5rFbLv1LcniDgHK3hUpEejMXCmsz9N-aMf0E_ftMwZsg@mail.gmail.com">
      <div dir="ltr">
        <div class="gmail_quote">
          <blockquote class="gmail_quote" style="margin:0px 0px 0px
            0.8ex;border-left:1px solid
            rgb(204,204,204);padding-left:1ex">
            <div>
              <div style="font-family:sans-serif">
                <div style="white-space:normal">
                  <p dir="auto">If we embrace “it is anonymous” I think
                    we get the cleanest experience. People won’t be
                    tempted to predict the name and refer to it somehow
                    (with reflection or even source code).</p>
                  <p dir="auto">If we embrace “it has a name you didn’t
                    pick” I think we get a simpler onramp story, but at
                    the cost of dark corners in the UE. Users will
                    immediately try to exploit the fact that the name is
                    semi-predictable, and write code that works with the
                    names of these classes.</p>
                </div>
              </div>
            </div>
          </blockquote>
          <div>After reading this (and the other thread), I'm more
            firmly convinced that using the file name is the right
            answer due to that "simpler onramp story".  It allows the
            unnamed class to have a stable name which enables growing it
            to have proper constructors, referencing it from other
            classes, etc.  Users trying to predict are learning more
            advanced features and will be ready to upgrade their classes
            to have explicit names.  It becomes a much smaller step to
            then add the opening "class Foo {"  & closing "}".</div>
        </div>
      </div>
    </blockquote>
    <br>
    This is a pretty compelling argument.  You start out with what
    appears to be a "naked" method, you add some more methods, maybe
    variables (sorry Remi) and helper classes, and then at some point,
    the teacher explains "class".  And then says, "hey, you didn't
    realize it, but you already wrote some classes!"  (Cue "you're
    soaking in it" commercial clip from the 70s.)  <br>
    <br>
    There's a seed of this argument already in the initial writeup,
    where the `this` receiver has been lurking in the background, and we
    mostly didn't notice or ignored it.  Its there in all the methods,
    we had no reason to hide it, we are just not shining the spotlight
    on it.  Dan, you're saying "exact same thing for the class name".<br>
    <br>
    But, I hear John say, this implicit class sucks, it has a name
    derived from some arbitrary artifact, maybe its name is FOO because
    the file system isn't case sensitive, etc.  OK, well, if you need to
    use the name, and you don't like the implicit one, then .... give it
    a name.  You've just learned why we give classes names.  <br>
    <br>
    So having explored the alternatives a bit farther, I'm getting more
    comfortable with "accidental name".<br>
  </body>
</html>