Xref: utzoo comp.lang.eiffel:1479 comp.object:2952 Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!usc!cs.utexas.edu!sun-barr!newstop!exodus!red-dwarf!pallas From: pallas@eng.sun.com (Joseph Pallas) Newsgroups: comp.lang.eiffel,comp.object Subject: Re: CHALLENGE: heterogeneous collections Message-ID: Date: 29 Mar 91 02:40:56 GMT References: <1991Mar22.210725.29448@neon.S <1991Mar25.220525.11087@leland.Stanford.EDU> <26714:Mar2602:52:1891@kramden.acf.nyu.edu> <1991Mar27.183206.5506@leland.S Sender: news@exodus.Eng.Sun.COM Followup-To: comp.lang.eiffel Lines: 23 In <1991Mar27.183206.5506@leland.Stanford.EDU> hoelzle@leland.Stanford.EDU (urs hoelzle) writes: >The problem is (unfortunately) harder than "const": if you have a generic >type (say List), e.g.: >type List[T] = > ...... > procedure f(arg: T); >then the above problem pops up, even if f doesn't change the List (e.g. >"const arg: T" wouldn't change the problem a bit). The problem is >contravariance: for a List[SubT], f's signature is "procedure taking a SubT", >i.e. a more restricted type than T, violating contravariance. We've strayed far afield from the topic of heterogeneous collections, I'd say. The problem of the relationship between List[T] and List[U] when U is a subtype of T (which is definitely NOT a subtype relationship) is actively being researched. This problem doesn't go away in dynamically typed languages. joe