Path: utzoo!attcan!utgpu!jarvis.csri.toronto.edu!mailrus!csd4.csd.uwm.edu!uakari.primate.wisc.edu!ames!uhccux!munnari.oz.au!murtoa.cs.mu.oz.au!charlie!aragorn!rad
From: rad@aragorn.cm.deakin.oz.au (Robert Alan Dew)
Newsgroups: comp.lang.smalltalk
Subject: Re: Smalltalk types
Message-ID: <7785@charlie.OZ>
Date: 4 Sep 89 13:56:54 GMT
References: <56929@aerospace.AERO.ORG> <7784@charlie.OZ>
Sender: root@charlie.OZ
Reply-To: rad@aragorn.UUCP (Robert Alan Dew)
Organization: Department of Computing & Mathematics - Deakin University
Lines: 85

>From: cook@hplabsz.HPL.HP.COM (William Cook)
>I think it is important not to become too caught up in object-oriented
>terminology.  One of OOP's big problems is its inability to
>communicate with the rest of the world.

I think OO terms should be used.  Where would we all be if new terms
(in any field) were not used?

>Types are abstract loose specifications that describe *what* messages an object
>handles, not *how* it handles them.

This is why class is attractive to me, a class specifies an object in
more detail than a type.

********************
>From: alan@ux.cs.man.ac.uk (Alan Wills)

>The main criterion for judging a definition of type is `does it give
>us a good way of separating those values which will support the desired
>behaviour of the program from those which won't, when they appear in a
>given context such as an assignment or message-argument?'

Including 'behaviour' indicates to me that you want to separate into classes
not types.  The current type definition excludes any behaviour of the object.

>Russ Abbott's one is a lot more useful: a type is the set of
>objects that respond to a particular set of messages.

This is not what Russ Abbott said.

>For example: say you
>invent a new sorting agent; it will accept a list of anything, and hand you
>back a sorted version; so long as the `anythings' understand `<'.  

Why are you associating a comparison procedure with the message '<'.
The message '<' does not imply what is written in the method.
eg. redirection in Unix is not a comparison.

>The idea that
>the set of all objects that understand `<' forms a type is clearly a useful
>one here.

If 'anything' understands '<' and each 'anything' also understands a
unique message then the 'anythings' are all of different types.
It is more important to be more specific, we need to know
whether the 'anythings' understand '<' not if they are of the same type.
But, understanding the message '<' is not strong enough.  It is the
method associated to the message which is important.

********************
The following three definitions of type have appeared in the
discussion so far.

>By  abbott@aerospace.aero.org (Russell J. Abbott)
>In Smalltalk, a type is a set of "messages" that objects of that type
>can receive.

>By  alan@ux.cs.man.ac.uk (Alan Wills)
>Russ Abbott's one is a lot more useful: a type is the set of
>objects that respond to a particular set of messages.

>By  cook@hplabsz.HPL.HP.COM (William Cook)
>Types are abstract loose specifications that describe *what* messages an object
>handles, not *how* it handles them.

I think the first two are trying to say:
Objects that respond to a particular set of messages are of the same type.
This definition indicates that an object can belong to many types.
eg. a set of objects respond to m1, => type A.
    a subset of the first set union another disjoint set respond to
    m2, => type B.
    therefore objects in the subset are of type A and type B.

How about this one?

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

Robert Dew   rad@aragorn.cm.deakin.oz