Xref: utzoo comp.lang.misc:7082 comp.object:2895 Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!sun-barr!newstop!exodus!red-dwarf!pallas From: pallas@eng.sun.com (Joseph Pallas) Newsgroups: comp.lang.misc,comp.object Subject: Re: CHALLENGE: heterogeneous collections Message-ID: Date: 26 Mar 91 17:23:19 GMT References: <22032@yunexus.YorkU.CA> <11820:Mar1923:59:3591@kramden.acf.nyu.edu> <19MAR91.22493670@uc780.umd.edu> <18271:Mar2013:19:1091@kramden.acf.nyu.edu> <1991Mar20.214231.3411@neon.Stanford.EDU> <1991Mar22.210725.29448@neon.Stanford.EDU> <1991Mar25.220525.11087@leland.Stanford.EDU> Sender: news@exodus.Eng.Sun.COM Followup-To: comp.lang.misc Lines: 59 In <1991Mar25.220525.11087@leland.Stanford.EDU> hoelzle@leland.Stanford.EDU (urs hoelzle) writes: >I think a few clarifications are in order because you're attacking on >the wrong front, Joe: I didn't intend to attack, just to make a point. Heterogeneous collections just happens to be one of my buttons. Also, I shouldn't have portrayed you as an "opponent of static typing" when you were merely presenting one argument against static typing. >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], especially if someProc just iterates through the > list and sends 'foo' -- after all, every SubT "is a" T. But as soon as > Lists are mutable (e.g. define insert(newElem: T)), the type system > won't let you do it because List[SubT] is *not* a subtype of List[T]. Aha! There's no heterogeneous collection here. There is, however, a problem with the notion of subtyping for parameter conformance. One solution to an overly restrictive static type checker is to weaken the static checking. Another solution, however, would be a smarter checker. > 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. Indeed. If I could provide more information about someProc, such as the fact that it never attempts to modify its parameter (did I hear someone cough "const"?), then even a simple type checker would be happy to approve this operation. Urs is correct that subtyping is NOT the right way to express this relationship. Subtyping is too strict a conformance relation. >3. At least for rapid prototyping, your argument that "the type > hierarchy isn't perfect if this situation occurs" is invalid: you > *don't* want to rearrange lots of types just to try something > out. This is a fairly strong argument. A good programming environment could go a long way toward neutralizing it, however. I confess I'm not aware of any that really eliminates all the effort involved in making this kind of change. On the other hand, I rely on static type checking during my rapid prototyping. It helps me to keep my mental model synchronized with the code I'm actually manipulating. I also find that the more OOP I do, the less often that I make major changes during prototyping without going all the way back to rethink the design. Maybe I'm fossilizing. There are just opinions, of course, and your mileage may vary. joe