----- Mail original ----- > De: "daniel smith" <daniel.sm...@oracle.com> > À: "Remi Forax" <fo...@univ-mlv.fr> > Cc: "amber-spec-experts" <amber-spec-experts@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 <fo...@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
