Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!cornell!uw-beaver!uw-june!rkr
From: rkr@cs.washington.edu (R. K. Raj)
Newsgroups: comp.lang.smalltalk
Subject: Re: Smalltalk types
Message-ID: <9120@june.cs.washington.edu>
Date: 5 Sep 89 01:17:05 GMT
References: <56929@aerospace.AERO.ORG> <7784@charlie.OZ> <7785@charlie.OZ>
Reply-To: rkr@june.cs.washington.edu.cs.washington.edu (R. K. Raj)
Organization: Computer Science Department, U Wash in Sea
Lines: 54

Here is my $.02 to the types discussion. William Cook (rightly, imho) points
out that "it is important not to become too caught up in object-oriented
terminology".  On the other hand, Robert Alan Dew thinks that "OO terms
should be used."  I believe that we should use object-oriented terminology
but should relate the terms we use to those in traditional programming, as
well as terms used in other object-oriented programming languages. One of
the biggest problems in understanding object-oriented programming is that
there isn't ONE STANDARD terminology: people tend to use the words they
learned in their first object-oriented language/system, and there sure are
lots of such first object-oriented languages!

Many problems are thus caused by the use of the same `English' word to mean
different programming concepts. That's where the problem with `class' and
`type' comes in: some people tend use these terms synonymously, others use
`class' as a description of complete object implementation and `type' as a
description of the object interface. There are other minor and major
variations on the usage of these terms, as well as those of other terms. I
believe that one should try to understand and appreciate the underlying
concepts of an object-oriented programming language rather than get
religious about the words that are being used to describe the concepts!!!

Having said all this, let me add on to the confusion. An ABSTRACT type is a
set of message specifications for an object while a CONCRETE type (aka class
in many languages) is a description of the implementation of the object.
Both these aspects are useful in their own way. It is usually a good idea to
keep in mind whether any discussion is about abstract or concrete aspects of
a type/class/whatchmacallit.

Just one more thing. Robert Dew (rad@aragorn.cm.deakin.oz) has suggested
the following definition of type equivalence:

>Let O be the set of all objects.
>Let M be the set of all messages.
>Let S denote a subset of M.
>Let T:O -> S be a mapping from an object to a set of all messages the object
>understands.
>
>Two objects o1 and o2 are of the same type iff
>		T(o1) = T(o2).

The concept of conformity is useful in object-oriented languages in
extending the notion of type equivalence. We should be interested in knowing
when one object can be used in place of another. For instance, using the
above notation, we can say that o1 can be used in place of o2 iff
        T(o1) is a superset of T(o2).  
In other words, o1 conforms in type to o2. Such a notion of type conformity
was first used in Emerald and Trellis/Owl, respectively described by Black
et al and Schaffert et al in papers in the 86 OOPSLA. Eiffel also has
something called conformance (see Meyer's book), but William Cook has
pointed out several problems in Eiffel (see Cook's paper in ECOOP 89).

  - R. K. Raj
    rkr@cs.washington.edu
    rkr@uw-june.UUCP