Class & interface terminology

[forax at univ-mlv.fr]

----- Mail original -----
> De: "daniel smith" <daniel.smith at oracle.com>
> À: "Remi Forax" <forax at univ-mlv.fr>
> Cc: "amber-spec-experts" <amber-spec-experts at openjdk.java.net>
> Envoyé: Jeudi 7 Mai 2020 23:06:44
> Objet: Re: Class & interface terminology

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

No, i disagree about to things
- trying to tilt each features to be either an interface or an class is not appropriate
- use classes or interfaces as a kind of composed word with the same meaning as "declared type". 

I don't say that the JLS should not be fixed, as you are showing the is a lot of case where by example, inner class also means local class or declared types shouls also includes type parameters.
But using "class and/or interface" goes in the opposite direction for me, it's not a specific term.

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

Disagreeing by citing one things allowed by both an annotation type and interface is not an argument, it's an anecdote. As i said in my previous mail, the annotation type is a small part of the annotation feature.

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

i would hope it says the enum is final or not, not the underlying class.

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

i would hope the JLS talk about record and abstract record.

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

I can only trust you on this, I still thing that using "class and/or interface" is not the good term.

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

I think you know far more than me on this subject, because i have still no idea on what is partially specializable or not.

Rémi