Anonymity and observability of unnamed classes (JEP 445)

[Attila Kelemen]

Brian Goetz <brian.goetz at oracle.com> ezt írta (időpont: 2023. máj. 7.,
V, 22:22):
>
> I think you may be misunderstanding the use of “dialect” here.  By “dialect” we don’t mean that the language is given semantics it didn’t have before; every new language feature does this.  By dialect we mean a set of “beginners semantics” for these new compilation units that would be *different* from the same code in a full program.  This would require students to “unlearn” as they scale up, rather than merely “zoom out”.
>

I'm certain that I'm misunderstanding it, but I don't think exactly
for the reason you are describing it here (that is, I don't mean it
because of the new semantics). This was my (untold) line of thinking:

1. It sure sounds silly, but I thought (before Rémi fixed me) that
unnamed classes actually have a defined name (to be able to specify
the name of the main class for when you are not running a `java` with
the source file as the input). But I was corrected that unnamed
classes are actually ... unnamed :) (side note: I feel that
"anonymous" and "unnamed" used as a term to mean different things will
lead to confusion in the future).

2. Given (1) - as Rémi put it - this JEP is not for normal Java coding
(by normal, I mean for what people usually use Java for today), but
for programming in the small.

3. That is - as I interpreted this - we now have a slightly special
syntax for "programming in the small" and another for the "rest". This
is what I considered as a "separate dialect". A dialect for
programming in the small, and a dialect for normal Java programming.

4. Compared to this, I just don't feel like implicit static is really
a different dialect given that we have implicit static for interface
fields. And implicit static makes sense for me, because obviously
there is no reason an interface would ever be non-static. Similarly
here, one could argue that there is no reason why you would like to
distinguish between static and non-static in these new classes. Given
that we are talking about a singleton implementing no interfaces and
extending only `java.lang.Object` (as methods of such an object are no
better than static methods).