wilson@carcoar.Stanford.EDU (Paul Wilson) (09/05/89)
It seems to me that types are abstracted *roles* that objects can play.
The same set of messages may mean a different thing in one role
than in another, so sets of messages really don't capture this
intuition.
For example in my role as a computer scientist, if somebody asks
me "what do you do?" I respond in one way, but in my role as
a boardsailer, I respond in another. So at a conference, I
may say "garbage collection and reconstructive memory," but
at the beach I say "I fall down a lot."
Similarly, when an object is of more than one type, you get
collisions between messages understood by one type and same-named
messages understood by another. For example, suppose a window
object responds to a "size" message by returning a point object
giving its screen dimensions in pixels; suppose also that
a queue object responds by returning an integer saying how
many things are in the queue.
What happens when an object is both a queue and a window (say,
because it's a queue that can represent its contents to the
user)?
It seems to me that the "right," intuitive way to do this,
in a strongly typed system, is to resolve this by the
role the object is playing. If the window system has
a pointer to it *as a window*, it should respond as
a window. And if a simulation object has a pointer to
it *as a queue*, it should respond as a queue.
Does anybody do types this way? It seems to me the most
natural way to do things: if an object is of multiple
types, it has multiple interfaces -- different "languages"
it can speak. And different languages may have the same
words, but with different meanings. That's okay, as
long as the object knows what language it's being
spoken to in.
In summary:
A type should be a role with an associated protocol.
That's different from a set of messages, since two
different protocols could use exactly the same message
selectors and mean entirely different things.
And a class is a particular implementation that implements one
or more types. Note that all of these things have identities
rather than just properties; even types should be testable
for identity as well as the strucural equivalence
implied by accepting a particular set of messages.
Now it's not clear to me that making all these distinctions
is actually worthwhile.
Any comments?
-- Paul
Paul R. Wilson
Software Systems Laboratory lab ph.: (312) 996-9216
U. of Illin. at C. EECS Dept. (M/C 154) wilson@bert.eecs.edu
Box 4348 Chicago,IL 60680