Xref: utzoo comp.lang.misc:7123 comp.object:2930 Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!zaphod.mps.ohio-state.edu!swrinde!cs.utexas.edu!uunet!pdn!tscs!tct!chip From: chip@tct.uucp (Chip Salzenberg) Newsgroups: comp.lang.misc,comp.object Subject: Re: CHALLENGE: heterogeneous collections Message-ID: <27F11B1A.62B6@tct.uucp> Date: 27 Mar 91 22:22:17 GMT References: <1991Mar22.210725.29448@neon.Stanford.EDU> <1991Mar25.220525.11087@leland.Stanford.EDU> Organization: Teltronics/TCT, Sarasota, FL Lines: 28 According to hoelzle@leland.Stanford.EDU (urs hoelzle): >2. Here's why you want at least some form of heterogeneous collections: > > type T = "some type" > type SubT = "subtype of T" > > procedure someProc(c: List[T]) > > I think that you'll agree with me that you'd like to use someProc with > a Collection[SubT] ... Actually, I don't agree. And the burden of proof lay with the person who says "X is necessary." > In a way, the problem exists because today's type systems are based on > what you *could* do to the list in someProc, not on what you actually do. Without giving the compiler knowledge of the implementation of someProc, that restriction is rather difficult to escape. >3. At least for rapid prototyping, your argument that "the type hierarchy > isn't perfect if this situation occurs" is invalid ... Granted. Always tradeoffs... We here don't do rapid prototyping. -- Chip Salzenberg at Teltronics/TCT , "All this is conjecture of course, since I *only* post in the nude. Nothing comes between me and my t.b. Nothing." -- Bill Coderre