Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!iuvax!uxc.cso.uiuc.edu!uxc.cso.uiuc.edu!m.cs.uiuc.edu!p.cs.uiuc.edu!johnson
From: johnson@p.cs.uiuc.edu
Newsgroups: comp.lang.smalltalk
Subject: Re: types with identity > protocols, no
Message-ID: <80500076@p.cs.uiuc.edu>
Date: 12 Sep 89 03:41:00 GMT
References: <11712@polya.Stanford.EDU>
Lines: 25
Nf-ID: #R:polya.Stanford.EDU:11712:p.cs.uiuc.edu:80500076:000:1083
Nf-From: p.cs.uiuc.edu!johnson    Sep 11 22:41:00 1989


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

I don't do types that way, but I do OBJECTS that way.  In other words,
I wouldn't define one object, but two separate objects that make up
a multifaceted object.  If you want a window then you get a window
object (probably the "window" message retrieves it) and if you want
a queue then you get a queue object.  The queue and the window know
about each other and can be thought of as different facets of a complex
object, but are implemented as separate objects.  This seems simple
and easy both to implement and to think about.  Most o-o windowing
systems work this way.

Ralph Johnson