<!DOCTYPE html><html><head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
</head>
<body><div style="font-family: sans-serif;"><div class="markdown" style="white-space: normal;">
<p dir="auto">On 19 Oct 2022, at 9:43, Brian Goetz wrote:</p>
</div><div class="plaintext" style="white-space: normal;"><blockquote style="margin: 0 0 5px; padding-left: 5px; border-left: 2px solid #777777; color: #777777;"><p dir="auto">The alternative is to view these as _implicitly named_ classes, where they have a name, just derived from the file system rather than the source code.</p>
</blockquote></div>
<div class="markdown" style="white-space: normal;">
<p dir="auto">I’d like to discourage this idea. We already have nameless classes with non-denotable names, and programmers know how to use them. We don’t really have implicitly-named classes. (Except maybe in a weak sense for certain well-defined bytecode names like <code style="margin: 0; padding: 0 0.4em; border-radius: 3px; background-color: #F7F7F7;">pkg/Foo$Bar</code>, for member classes which already have an explicit name <code style="margin: 0; padding: 0 0.4em; border-radius: 3px; background-color: #F7F7F7;">Foo.Bar</code>; arguably <code style="margin: 0; padding: 0 0.4em; border-radius: 3px; background-color: #F7F7F7;">Foo$Bar</code> is an implicit name. But it cannot appear in source.)</p>
<p dir="auto">If we introduce a new way of naming (implicit names) we will have to roll out rules for mapping the name-precursor (a filename) to a name. This will have its own headaches, since different OSs have different alphabets and syntaxes, and none of those alphabets or syntaxes are fully compatible with native Java class names. So we’d have to saddle ourselves with a name mangling scheme to launder a random filename into a source-denotable Java class name. If ever there was a siren song, this is a loud one!</p>
<p dir="auto">Maybe the first place you’d want a name is a constructor declaration, not as an API point but as a place to put random setup code. Instance initialization blocks (though nobody loves them) supply a workaround for placing such random setup code. I suppose we could put some lipstick on them by allowing (eventually requiring) them to start with a keyword like <code style="margin: 0; padding: 0 0.4em; border-radius: 3px; background-color: #F7F7F7;">class</code> or <code style="margin: 0; padding: 0 0.4em; border-radius: 3px; background-color: #F7F7F7;">this</code>, in parallel to <code style="margin: 0; padding: 0 0.4em; border-radius: 3px; background-color: #F7F7F7;">static</code> for static initialization blocks. Or (different lipstick shade) allowing the init-blocks to somehow attach to field declarations, since that’s how they are used in many cases (both static and non-static).</p>
<p dir="auto">Since the next-best workaround is to give the class a name, or use a nested class to carry all the logic, and since that next-best workaround is not too expensive, I think the payoff for adding such lipstick is really small, but it’s something I’ve thought of before and might be worth keeping in the back pocket.</p>
</div></div></body>
</html>