Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!zaphod.mps.ohio-state.edu!casbah.acns.nwu.edu!nucsrl!tellab5!laidbak!mcdchg!mcdphx!udc!preece From: preece@urbana.mcd.mot.com (Scott E. Preece) Newsgroups: comp.object Subject: Re: A Hard Problem for Static Type Systems Message-ID: Date: 15 May 91 18:14:02 GMT References: <554@eiffel.UUCP> <1991Apr26.203642.17387@leland.Stanford.EDU> <556@eiffel.UUCP> <52166@nigel.ee.udel.edu> <1991May1.143831.2065@maths.nott.ac.uk> <1991May3.184332.28319@visix.com> <1991May3.212005.29453@visix.com> Sender: news@urbana.mcd.mot.com (news) Distribution: comp Organization: Motorola MCD, Urbana Design Center Lines: 41 In-Reply-To: amanda@visix.com's message of 3 May 91 21:20:05 GMT Nntp-Posting-Host: etude.urbana.mcd.mot.com In article <1991May3.212005.29453@visix.com> amanda@visix.com (Amanda Walker) writes: | | ... A trivial example of this idea is that a heapsort | should operate on any set of objects for which I can provide | comparison and exchange operations. --- OK, let me expose my ignorance[1]. I'd like to see how object-oriented design works. Would you care to sketch the design for this? My naive model would be that a heap is an object and that it has add and remove methods to take objects of unspecified type and stick them into the heap in the right place. So where do the comparison and exchange procedures go? I see two alternatives[2]: (1) the heap object has compare and exchange methods that "know about" all of the types, figure out what's involved, and operate on the member objects or (2) the objects have methods that report their "comparable value" and size in canonical forms that a generic routine in the heap object can operate on. Neither of these makes me awfully happy. In case (1) the heap has to know much too much about the objects, making it hard to believe that the desired level of reusability can be reached. In case (2) we have removed the heap's ability to choose what attribute of the object is used for sorting, since the object owns production of the sort key. So where is "the right place" to put the comparison and exchange knowledge, in the heap, in the objects living in the heap, or somewhere else that I missed entirely? NOTES: [1] I first used SIMULA in 1973, but the way I used it didn't look much like what people seem to be saying about o-o today. I have a little trouble with the notion that process should go away and design should be strictly composition of objects (I've seen several statements along those lines). At any rate, I'm being quite honest here in asking for examples of how an experienced O-O designer would think about the problem. [2] Well, actually, of course, I see a lot of other alternatives, but they mostly could be characterized as one of these, with embroidery. -- scott preece motorola/mcg urbana design center 1101 e. university, urbana, il 61801 uucp: uunet!uiucuxc!udc!preece, arpa: preece@urbana.mcd.mot.com phone: 217-384-8589 fax: 217-384-8550