Class & interface terminology
Alex Buckley
alex.buckley at oracle.com
Thu May 7 21:02:22 UTC 2020
On 5/7/2020 11:48 AM, Dan Smith wrote:
> I'll add that it's useful to think in terms of three different entities:
>
> 1) Class and interface declarations. These are syntax. Example: "interface List<E> ..."
> 2) Classes and interfaces. These are "symbols". Example: the interface List
> 3) Class and interface types. These are a kind of type. Example: the type List<String>
>
> There's a one-to-one relationship between class/interface
> declarations and classes/interfaces. There is, in general, a
> one-to-many relationship between classes/interfaces and types. (More
> accurately, types can use classes and interfaces however they like to
> describe sets of values.)
Thank you Dan. The First Edition of the JLS revolved around
type declarations of class and interface types
because (2) and (3) were the same thing in 1996. Less than 10 years
later, JSR 14 had introduced a plethora of new terms -- generic types,
parameterized types, raw types, reifiable types -- which the Third
Edition of the JLS integrated heroically, but without the exhaustive
analysis that you have performed here. I look forward to a future JLS
that revolves around
class and interface declarations of classes and interfaces.
Speaking of "generic", I would be grateful if you can clarify (maybe
here, in the first instance, then later in the draft) :
- A generic class or interface declaration begets a generic class or
interface. (1.1 "Class and interface declarations may be generic" + 8
"Classes may be generic ...")
- A generic class or interface begets many parameterized class or
interface types.
- A generic method declaration begets a generic method, which undergoes
generic method invocation.
It would be good to enhance the introduction of the draft to acknowledge
the common terms "static type" (perhaps in connection with "A class type
or an interface type is [a] variable or expression type") and "dynamic
type".
I confess to similar twitchings as Remi in relation to "annotation
interfaces". (Not "enum classes", or "record classes" -- all good
there.) My concern is that 99% of conversations around metadata in Java
programs are interested in the `@Foo` annotations appearing around their
source code, not about the Foo annotation interface defined far away by
someone else. That is, "annotation" usually means "an instance,
providing literal values for the elements of the annotation interface",
and not "a declaration of an annotation interface" ... yet the draft has
"annotation" as "a declaration":
An annotation declaration specifies a new annotation interface,
a special kind of interface.
What you're saying here is: Just like a class declaration introduces a
class Foo, which `new` turns into an object (an instance of class Foo),
an annotation declaration introduces an annotation Foo, which `@` turns
into an object (an instance of annotation Foo). I always thought of the
annotation as being `@Foo`, not `Foo`, though I concede that people will
_say_ "Look at the annotation Foo here, it means ..." while pointing to
the character sequence `@Foo`.
Alex
More information about the amber-spec-experts
mailing list