Which is a type of objects in mainstream OO languages: a class, an interface, an abstract class, a metaclass?

Question

In Types and Programming Languages by Pierce, Section 18.6 Simple Classes in Chapter 18 Imperative Objects says:

We should emphasize that these classes are values, not types. Also we can, if we like, create many classes that generate objects of exactly the same type. In mainstream object-oriented languages like C++ and Java, classes have a more complex status—they are used both as compile-time types and as run-time data structures. This point is discussed further in §19.3.

The only place which Section 19.3 Nominal and Structural Type Systems says about classes is:

These type names play a crucial role in Java’s subtype relation. Whenever a new name is introduced (in a class or interface definition), the programmer explicitly declares which classes and interfaces the new one extends (or, in the case of a new class and an existing interface, “implements”). The compiler checks these declarations to make sure that the facilities provided by the new class or interface really extend those of each super-class or super-interface— this check corresponds to record subtyping in a typed lambda-calculus. The subtype relation is now defined between type names as the reflexive and tran- sitive closure of the declared immediate-subtype relation. If one name has not been declared to be a subtype of another, then it is not.

Does the above quote or some other places in Section 19.3 explain the second highlighted sentence in the first quote from Section 18.6, i.e. why

In mainstream object-oriented languages like C++ and Java, classes have a more complex status—they are used both as compile-time types and as run-time data structures

? (I don't see Section 19.3 mentions that a class is a type of objects in mainstream OO languages, and even explains it.)

In Chapter 18 Imperative Objects, is an interface a type of objects?

In mainstream OO languages (such as Java, C#, I am not sure if C++ has interface),

• is an interface a type of objects?

  An interface seems to me a type of classes, since many classes can implement the same interface. Since a class is a type of objects, is an interface a kind?

• Is an abstract class essentially the same concept as an interface? (In terms of being a type of classes or something else)

• in Python, there is another concept "metaclass". Is a metaclass a type of object, a kind, or something else?

I have a related post a while ago: Is the implementation relation between an interface and a class an instantiation or inheritance relation, or neither?. It also introduces concept "metaclass" of Python, and my confusions between interface, class, abstract class, and metaclass. Appreciate if you could also take that into account.

Thanks.

Answer 1

Unfortunately I don't have a copy of TAPL with me, so I can't figure out exactly what the author intends. But there is a point we should make, that types are something which classifies terms or values, even if there are other pieces that are related to the type.

As such, classes and interfaces are not literally types themselves in Java or C++. Rather, each instance of a class/interface defines a few things simultaneously:

• At runtime, we associate with each such defined class, a table of details. This can include where to find code for overrideable methods, but also information like which methods exist, what fields and the like, for reflection.
• Both at compile time, and runtime, it defines a type with the same name, which denotes those objects whose runtime class is a subclass of said class. So here we have a distinction we can make: Each object has exactly one class, but belongs to potentially many different types (the transitive reflexive closure of the subtyping relation).

This is different from the situation in something like OCaml, or likely, those simple objects in TAPL. If there is no means of distinguishing which class created an object, we likely do not want to associate it with a type (as we cannot do anything different with it). In particular, classes in OCaml define a means of constructing an object, so they are a value (just as in the function x -> x + 2).

Following this reasoning, we can think about what metaclasses imply for Python. When we define a metaclass, it creates a particular object, much the same as any other Python object. This portion is a value. Now, later code may reference that value for construction of classes. As stated, we haven't quite made them relate to types yet.

And from here, the answer really comes down to what we decide the types are. It is reasonable to say that objects have a type based on their class (Note again, this is distinct from the denotation given by the type function in Python, which returns a value related to our type). In this situation, yes, metaclasses can be considered to define a kind, as to each class-type, we have an associated metaclass. But we'd be just as reasonable to not consider anything here to be types, and to work only with values and functions.

To really talk about this, we might want to say that Python has a reflection principle: for every class value, we have an associated class type, and vice versa. Extending this we can talk about metaclasses as kinds, (but that will begin requiring subkinding, which may be undesirably complex).

So the key point of distinction we come down to is this: types are classifications, and values are concrete data structures. There can certainly be relations in languages which have run-time type information, but they are not literally identical, and there may be multiple sorts of things defined simultaneously.

Answer 2

There is just nothing that you can generalise. Every language is different.

A class describes what instances of the class (objects) look like. In Java, a class is also an object in its own right. All classes are instances of a class named "class", which allows the programmer to ask the class for example "what is your name", "what are the instance variables of your instances" and so on.

An interface describes what are the requirements for a class so it can claim it implements the interface. Again, in Java an interface is also an object in its own right. In Java, there are no instances of an interface. There are only instances of classes, and some classes implement some interfaces, so you can say "this object is an instance of some class that implements the interface".

C++ doesn't have interfaces. Some people claim that abstract classes are interfaces, they are not.

In Swift, "interfaces" are called protocols, and protocols actually have instances (which refer to some other object that implements the protocol).

So every language is different.