Class & interface terminology

[Dan Smith]

> On May 7, 2020, at 1:47 PM, Remi Forax <forax at univ-mlv.fr> wrote:
> 
> There is a good reason why it is done that way, i.e. enum is called enum and not enum class or annotation type is not called annotation interface.
> It's to avoid the confusion between the feature of the language and its translation strategy, an annotation type is not an interface, the translation strategy uses an interface (and some attributes), but it's not an interface, an enum is not abstract despite the fact that it can be translated to an abstract class, etc.
> 
> This can even be dangerous, if we then want by example introduce a more abstract record that is translated to an interface. The feature is record, not record class, like the feature is enum, not enum class.
> 
> Moreover, this has been discussed ad-nauseam during the Java 5 timeframe, i don't see the point to change that now.


To contextualize this: you're expressing a narrow concern that "enum" -> "enum class" and "annotation type" -> "annotation interface" may not be appropriate renamings, and that these were (maybe?) intentionally avoided when those features were designed. "Record" -> "record class" would have similar issues.

I disagree with the assertion that an [annotation type/interface] is not an interface. JLS Chapter 9 is quite clear that an [annotation type/interface] is a special kind of interface. Among other things, this means that you're allowed to declare a class that implements an [annotation type/interface].

Same comment for [enums/enum types/enum classes] and Chapter 8. 8.9 doesn't say anything about whether the class is 'abstract', but it is clear that the class may or may not be 'final', depending on the format of the enum constants.

None of this has anything to do with translation strategy. We're just talking about the language and the entities it uses to describe its semantics.

If, per your example, we were to introduce a form of record declaration that specifies an interface, we would need to say so explicitly, and start talking about "record classes" and "record interfaces". Among other things, this distinction might matter so that I would know whether I'm supposed to 'extend' it or 'implement' it.

Anyway, there's nothing wrong with saying plain "enum" or "record" when you're talking about these features. We do so quite a bit in JEP 384 (Records Second Preview), for example. In some contexts, though, precision is important, and in those contexts, it's useful to emphasize the fact that an [enum/enum type/enum class] is just one kind of class, and so everything that talks generally about "classes" is talking about them, too. (There are, in JLS 14, a number of partial efforts to say "or enum type" when talking about classes and interfaces, but it's totally ad hoc, nowhere near universal, and, it turns out, not necessary.)

> Yes it means that "type" is overloaded but it's part of our heritage, yes, this means you have to use static type and dynamic type sometimes where you can use type and class, but i don't see the point to change something that was agreed 20 years ago. In fact, it seems to be the worst time to introduce such change, soon we will introduce reified generics that may force us to redefine the exact relation between a class and a type for the language and the VM so it's wiser to wait until we all have a clear vision of how things work, instead of changing things for the sake of changing them.

I think this is a more general critique about avoiding "type" when what is meant is "class or interface".

A couple of points:

- I don't think anything was ever "agreed to", and I don't think this is a wholesale change. The language has evolved over the years, with different pieces violating assumptions that made sense before, and the use of terminology evolving in piecemeal fashion to keep up. The goal here is to standardize what has evolved across all the pieces. In some cases that means changing terminology A to align with B (e.g., existing uses of "type declaration" and "class or interface"), but the status quo is that A and B are inconsistent, so to produce something consistent, something has to change.

- I think you're overestimating the footprint of the change here. This isn't a "redesign all the terminology from scratch" exercise. It's making some adjustments around the edges to keep things in good shape. Those changes touch a lot of things; but if, say, we were to embrace "type" as the standard way to say "class or interface", a lot *more* things would need to change.

- Considerations for Valhalla are very much a part of why this is at the top of my mind. The point is not to define precisely the relationship between classes and types. Instead, the point is to recognize that *these are distinct entities*, and there is space in the design for different kinds of relationships between them. We have a clear enough vision at this point to know that making such a distinction is likely to be an important part of whatever Valhalla ends up doing.