Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!uwm.edu!bionet!parc!mdixon From: mdixon@parc.xerox.com (Mike Dixon) Newsgroups: comp.object Subject: Re: Global program state. Message-ID: Date: 8 Jan 91 01:07:34 GMT References: <330@coatimundi.cs.arizona.edu> <2474@motcsd.csd.mot.com> <2789008e.3fdf@petunia.CalPoly.EDU> Sender: news@parc.xerox.com Organization: Xerox PARC, Palo Alto, CA Lines: 23 In-Reply-To: jdudeck@polyslo.CalPoly.EDU's message of 7 Jan 91 23:13:18 GMT But from the programmer's perspective, object-oriented design encapsulates the screen, disk files, databases, comm channels, etc, as objects which have the behavior of that particular real-world entity. Thus the state aspects of those objects is still localized so as to help control complexity. the problem is that these objects aren't encapsulating the real state -- nor could any programming language construct. you can go ahead and define a disk file object that "encapsulates" and controls access to your disk file, but if i start sending arbitrary commands over the scsi bus all bets are off. of course, when the world is nicely structured (as computational worlds try to be), you can construct layers of objects, such that the encapsulation of objects in layer n can be guaranteed as long as i don't touch the objects in layers < n. but even this has limits; consider the case in which i can turn on a very strong magnetic field generator that happens to be next to the disk... -- .mike.