Path: utzoo!attcan!uunet!dino!ux1.cso.uiuc.edu!render
From: render@cs.uiuc.edu (Hal Render)
Newsgroups: comp.object
Subject: Re: Types vs. Classes
Keywords: types, classes, OO
Message-ID: <1990Sep27.174122.2293@ux1.cso.uiuc.edu>
Date: 27 Sep 90 17:41:22 GMT
References: <60700001@inmet>
Sender: news@ux1.cso.uiuc.edu (News)
Organization: U. of Illinois, Dept. of Computer Science, Systems Research Group
Lines: 76

In article <60700001@inmet> stt@inmet.inmet.com writes:
>I would like to begin a discussion on the distinction,
>if any, between "types" and "classes".  There seems to be
>no consistent distinction made between these two in the OOP literature.  
>I have seen a type considered an implementation of a class, a class
>as an implementation of a type, the two considered
>synonyms, etc.  
>
>Here is a proposed distinction:
>
>1) Each value has a *unique* "type"
>2) A value may be a member of one or more "class"es, determined
>   by the type of the value.
>
>Essentially, the type structure is considered a "partitioning"
>of the value space (i.e. types are non-overlapping), 
>whereas the class structure is a taxonomy (i.e. classes overlap
>and enclose one another).

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. 

>
>A class comprises a (potentially open-ended) set of types, 
>and a subclass is a subset of a class, comprising a subset 
>of the types in the superclass.  
>
>In formal terms, it is meaningless to ask "what is the class" of
>a given value.  However, this can be reinterpreted as
>"what is the smallest class which contains the type" of a given value.

In most OO languages that use classes, the class of an object
is understood to be the smallest class that contains the object, 
so your point seems rather moot.

>I prefer these definitions, because I think they are consistent
>with the use of the term "type" in strongly-typed non-OOP languages,
>and consistent with the use of the term "class" in OOP languages.

As I've said, if types are non-overlapping then we have to throw
out any language that allows the definition of subranges and subtypes
such as Pascal, Modula-2, Ada, and others.  This seems a rather
arbitrary (and unnecessary) restriction.

>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.

There is difference of opinion on what a class is, since most definitions
are operational, i.e. they are drawn from an implementation of a particular
OOPL.  This is where the problem lies, I think.  A "type" has a widely
accepted mathematical definition (or so I understand from my PL theory 
friends) but none yet exists for "class."  This may be good, however, since
it allows OOPL developers room to explore.  I think a consensual definition 
of the "class" will come in time, but I think we're still in the midst
of discovering what we want and need it to mean given how we use them.

hal.