Paving the on-ramp

[John Rose]

On 19 Oct 2022, at 9:43, Brian Goetz wrote:

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

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 `pkg/Foo$Bar`, for 
member classes which already have an explicit name `Foo.Bar`; arguably 
`Foo$Bar` is an implicit name.  But it cannot appear in source.)

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!

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 `class` or `this`, in parallel to `static` 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).

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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/amber-spec-observers/attachments/20221019/e2029fc9/attachment-0001.htm>