Unnamed classes (was: Paving the on-ramp)

John Rose john.r.rose at oracle.com
Thu Oct 20 16:48:34 UTC 2022

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.)

More information about the amber-spec-experts mailing list