Path: utzoo!utgpu!news-server.csri.toronto.edu!rutgers!usc!wuarchive!swbatl!aslan!gilstrap
From: gilstrap@aslan.sbc.com (Brian R. Gilstrap)
Newsgroups: comp.object
Subject: Re: Types vs. Classes
Message-ID: <1990Sep27.152601.18632@swbatl.sbc.com>
Date: 27 Sep 90 15:26:01 GMT
References: <60700001@inmet>
Sender: usenet@swbatl.sbc.com (0000-news(0000))
Reply-To: gilstrap@aslan.sbc.com (Brian R. Gilstrap)
Organization: Southwestern Bell
Lines: 70


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.

What he continues with does not necessarily jibe with how I think of
things (could simply be that I didn't understand what he was saying).
So, in order to stir up discussion and perhaps have some misconceptions
of my own corrected, I'll give this a stab.

Every object conforms to one or more abstract types.  For example, a given
object might comform to the type "File", where "File" has been
defined as a set of signatures, invariants, etc. (e.g. an abstract type).
Note that there can be "anonymous" abstract types.  That is, there may
be an object which conforms to an abstract type, but we have not given that
abstract type a name.

However, we now get to the big split.  Some OOPLs, like Eiffel for example,
make classes hierarchies conform to type restrictions.  For example, a
sub-class of a class conforming to type "File" would be required to satisfy
the requirements for being a "File".  The sub-class might satisfy even more
stringent requirements, but it must at least be a "File".

Other OOPLs, like Objective-C, use the class hierachy primarily as a means
of code-reuse.  In these cases, the "every sub-class must conform to the
type requirements of all its super-classes" idea is not pursued.  That is,
my "NeatoFile" class would inherit from my "File" class because it saves me
a lot of implementation time.  However, a "NeatoFile" object might not behave
to an outside observer in the same manner as a "File" object, even if the
outside observer only invoked behaviors possessed by "File".  This means that
programming with these languages still involves (perhaps implicit) abstract
types.  That is, at any point in the program the programmer will be willing
to say "I expect every object used here will support at least the following
behaviors with the following arguments and return types".  This is, of course,
an abstract type.  Of course, it is rare that things are made this explicit,
and the programmer usually thinks "I expect every object used here will
be a-kind-of ______".

It is still possible to say that every class conforms to some abstract type,
regardless of whether it is "strongly" or "weakly" typed.  It is just that
in the "strongly" typed languages the typing information is used to (1)
require that no attempt is made to invoke a behavior which is not supported
by the abstract type, and (2) to aid in efficiently translating the program
into machine code by allowing various kinds of optimizations.  In the "weakly"
typed languages, type checks are left to runtime and abstract type 
information is not used in optimizing the program to machine code.


Where does this leave us?  Good question.  If someone can come up with a
succinct way of putting all that, I'd be very interested in seeing it.


And please, let's not turn this into another "strongly typed" versus
"weakly typed" OOPLs war.


Brian R. Gilstrap
gilstrap@aslan.sbc.com
gilstrap@swbatl.sbc.com
...!{texbell,uunet}!swbatl{!aslan}!gilstrap