Path: utzoo!attcan!uunet!mailrus!accuvax.nwu.edu!anaxagoras!aristotle.ils.nwu.edu!welter
From: welter@aristotle.ils.nwu.edu (Pete Welter)
Newsgroups: comp.object
Subject: Re: Display methods, pro or con...
Message-ID: <1303@anaxagoras.ils.nwu.edu>
Date: 8 Aug 90 14:17:36 GMT
Sender: news@anaxagoras.ils.nwu.edu
Organization: Institute for the Learning Sciences
Lines: 26
References:<1681@dinl.mmc.UUCP> <25966@bellcore.bellcore.com>

In article <25966@bellcore.bellcore.com> sjs@roland.ctt.bellcore.com (Stan 
Switzer) writes:
> I propose that it makes a lot of sense, even at the highest levels of
> design to keep separate the ideas of what an object *is* and what the
> object is *for*.  It is going to be difficult to tease apart the
> concepts of what we do *to* an object and what the object *does*.  Up
> to a point--but where?--an object should be free of teleological
> baggage.

As a beginning Mac Common Lisper (a language that supports multiple
inheritance), I wonder if the best way to deal with this is to use
multiple inheritence, mixing in the appropriate interface class with
the class that is to be displayed.  Is this a common practice in
languages that support multiple inheritance, and if not, why not?

Having done a few user interfaces in OO systems, I remember feeling
that building a parallel display class was sort of "wrong" (it 
seems to blow encapsulation), yet putting all kinds of display stuff
in an object really gets away from (as Stan says) what an object *is*.



Pete Welter
Institute for the Learning Sciences
Northwestern University
welter@aristotle.ils.nwu.edu