Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!swrinde!zaphod.mps.ohio-state.edu!rpi!bu.edu!inmet!stt
From: stt@inmet.inmet.com
Newsgroups: comp.object
Subject: Re: Types vs. Classes
Message-ID: <60700002@inmet>
Date: 28 Sep 90 19:26:00 GMT
References: <60700001@inmet>
Lines: 104
Nf-ID: #R:inmet:60700001:inmet:60700002:000:5249
Nf-From: inmet.inmet.com!stt    Sep 28 15:26:00 1990


Re: Types vs. classes

Render@cs.uiuc.edu writes:
>The problem with your definition is that it does not match my understanding
>of the use of the "type" even in  non-OO languages.  My informal understanding
>of a type is that of a set of values and a set of operations defined
>on those values.  For a structured type (a type that has values of other
>types as elements arranged in some fashion) there is also some expression
>of the relationship between the constituent types.  This does not preclude
>having overlapping types.  Intuitively, the numeric quantity represented by 
>the numeral 5 is both an integer value and a real value.  Does this not mean
>that 5 is a member of two different types?  If not, I'd like to know why
>not, since it violates my understanding of types as expressed in Pascal,
>Ada, and other strongly-typed programming languages. 

In a legal Ada program, every expression has a unique type, 
but certain expressions are implicitly convertible if they 
have "universal" type, to some other type in the same "class".  
I will admit this is a fine distinction, but at least theoretically, 
every expression has a unique type.
Values are the result of evaluating an expression, and are conventionally
considered to have the same "type" as the expression which computes them.
There are "corresponding" values in multiple types (i.e., each
numeric type has its own zero value), but they are not considered
the "same" value.

In the classic text by Dahl, Dijkstra, and Hoare, "Structured Programming,"
(Academic Press, 1972), Hoare states quite clearly on page 92:
"(3) In a higher-level programming language the concept of a type is
of central importance.  Again, each variable, constant and expression has
a unique type associated with it."

In a later chapter, the concept of a "sub-range" type is introduced.
These are considered distinct types, though convertible to
the "base" type of the sub-range.  In other programming languages,
sub-ranges have often been considered sub-types rather than distinct types.

One source of confusion is that "notations" like "5" are overloaded
in many languages, to be a value representing the concept of "five-ness,"
of a type determined by context.
Another source of confusion is that Ada uses the term "subtype"
to mean "a type plus a constraint" or a "subset of a type", *not*
to represent a distinct type in and of itself.  Pascal is a bit
more confused on this issue.

Again, I will admit that if two types are interconvertible,
implicitly or explicitly, then they may be said to overlap
in an informal sense, but, at least formally, they are considered
distinct, and any given value computed by an expression
is in one or the other.

To avoid confusion, it might be safer to use the term
"the result of an expression" rather than value,
and instead say:

1) The result of an expression has a single unique type
2) The result of an expression may be a member of
one or more classes, determined by its type.

I think this formulation even works for "type-less" languages
like Lisp, where types are associated with values, rather than
variables.

It is generally agreed that a type includes a set of values,
but it is not just a random collection, but rather
a very special kind of set:  First of all, all members of this
value set are usable with the type's operations.  And secondly, 
I would propose, any given "value" is only in one type's value set,
though there may be a "corresponding value" in another type's value set.

>>Actually, I think OOP languages tend to be a bit schizophrenic
>>about the term "class" already, since the term is used both
>>for parameters/references which may in fact refer to a value
>>in any subclass of the class, and to identify *the* class of a value (which
>>only makes sense if you use the interpretation suggested above
>>of "smallest class which contains the value").
>
>I've never seen a person refer to a variable as a class (which you seem
>to say) although one can constrain a variable/parameter/reference object
>to only contain or reference an instance of a specific class in some
>languages.  With such mechanisms, the difference between a class and a type
>is admittedly blurred.

I certainly didn't intend to equate a variable and a class (though
I admit my wording could be interpreted that way).  I meant
to say that the term class is used when specifying the "type"
of a pointer/reference, when, at least in C++, pointers/references
may in fact refer to any value in that class *or* one of its subclasses.
However, a variable in C++, when declared to be of a certain "class,"
may *not* contain a value of a subclass (it's not "big enough" to do so).  
This is the "schizophrenia" to which I was referring.

Using the proposed terminology, a variable in C++ has a single specified 
"type," whereas a pointer/reference refers to a "class" of types.
The C++ "class" X is defined to comprise the "type" X plus all types derived
directly or indirectly from X.  When calling a virtual
function given a pointer to a *class* X, the
*type* of the pointed-to object determines which specific
implementation of a virtual function is called.

S. Tucker Taft   stt@inmet.inmet.com   uunet!inmet!stt
Intermetrics, Inc.
Cambridge, MA  02138