What does Harper mean by "class"?

Question

I've been teaching myself type theory on and off over the past couple years. I've reach large sections of Pierce's Types and Programming Languages and Harper's Practical Foundations for Programming Languages, but there are still sections I need to either read for the first time or really understand.

In Harper's section on classes, this is his introduction:

It frequently arises that the values of atype are partitioned into a variety of classes, each classifying data with distinct internal structure. A good example is provided by the type of points in the plane, which may be classified according to whether they are represented in cartesian or polar form. Both are represented by a pair of real numbers, but in the cartesian case these are the x and y coordinates of the point, whereas in the polar case these are its distance, r, from the origin and its angle, θ, with the polar axis. A classified value is said to be an object, or instance, of its class. The class determines the type of the classified data, which is called the instance type of the class. The classified data itself is called the instance data of the object.

As far as I can tell, this does not align closely with objects as they are commonly understood in programming languages today. When I think of classes, I think primarily of encapsulation and inheritance, not of classifying different representations of a value.

Am I right in believing this is not the same definition of classes that is commonly used? Is this definition common in the academic community? Are there any programming languages where these kinds of classes are used?

Update

Since this question seems to have attracted some recent activity, I'll update with my current understanding.

We start with the general, abstract notion of a two-dimensional table. Each cell in the table specifies a function acting on a specified type. Thus, the rows are "classes" and the columns "methods" with dynamic dispatch.

If we take the row-oriented view, then we have the standard notion of a class in mainstream OOP languages: a record of functions acting on a specified type of data. If we instead take the less commonly considered column-oriented view, we have a function that uses case analysis on the type of its first argument. The fundamental take-away is that neither the row or column-oriented view is more natural; we must understand classified values as a two-dimensional table.

It does turn out that we need need sum types to implement this realization, but that is only one aspect. We also need product types, and then to view these product and sum types in the right light.

Answer 1

The term class here has absolutely nothing to do with OOP classes. Rather, a class determines which possibility in a C union an object takes.

For example, one definition of a binary tree is: a binary tree is either a leaf or a pair of binary trees. Leaves form one (boring) class, pairs of binary trees form another.

Mathematical terminology often uses words which have other meanings in common usage. You should get used to that.

Answer 2

This is a very generic, informal definition of the concept of classes which is commonly implemented in programming languages. I can't think of a programming language that uses the term “class” in a different sense, except where “class” is used in its everyday meaning where it is a synonym of “category”, “type”, “sort”, etc. You may not recognize it because this is only a small part of the class systems of the language(s) that you're used to, but that's the core of the concept.

Would you recognize a car engine if it was sitting there outside of a car? You don't need to have any idea what a car engine looks like to drive a car, but a book about building cars definitely needs to describe engines in detail. Engines don't look at all like a car (no wheels, no windows, …) but they are a core part of a care nonetheless.

An object consists of some data — the values of the instance fields — together with a class indication. A class is the type of all the objects with a given class indication, i.e. a class is a way to categorize objects. The intent of the class is to reflect the semantics of the instance fields. I don't have the book at hand, but I expect it to mention methods soon after, which are functions attached to an object or to the class (depending on whether they are virtual or static methods, to use common OOP terminology).

The definition is very generic and covers, for example, type classes as well as the class systems with dynamic dispatch that you're probably more familiar with.

Encapsulation and inheritance are common properties of object-oriented languages, but they are not inherent properties of classes: they are constructions that can be expressed in a language of classes. Encapsulation is done by allowing different classes to expose the same interface, typically either with a class-implements-interface as in Java or with a multiple inheritance system where a class implements only its ancestors as in C++. Inheritance is a mechanism whereby classes are defined from other classes by specifying the differences between the parent class and the derived class.