What does Harper mean by "class"? 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.
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.