On 20 Oct 2022, at 9:12, Brian Goetz wrote:
>> 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).
>>
>> 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.
>>
>> 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 "}".
>
> 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.)
>
> 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".
>
> 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.
>
> So having explored the alternatives a bit farther, I'm getting more
> comfortable with "accidental name".
Yeah, I’m getting there too after pulling on a string I liked more at first
than I do now. Thanks Dan.
Next question: If we are embracing accidental names, what are the rules for
the name-precursors? Can we extract an accidental name from any possible file
name in any possible file system? Or are there restrictions on the file names?
Since this is a pedagogical feature, I suppose we require the “.java” suffix
always, despite the inevitable requests for shebang script support.
And in particular, do we require that the basename of the file be a valid Java
identifier (and not a Java keyword)? So no “my-stuff.java” or “42.java” or
“goto.java”? Do you have to learn Java identifier syntax in the very first
place? (Seems reasonable to me at this moment.)
