Xref: utzoo comp.lang.eiffel:1471 comp.object:2920 Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!uwm.edu!bionet!agate!stanford.edu!leland.Stanford.EDU!leland.Stanford.EDU!hoelzle From: hoelzle@leland.Stanford.EDU (urs hoelzle) Newsgroups: comp.lang.eiffel,comp.object Subject: Re: CHALLENGE: heterogeneous collections Message-ID: <1991Mar27.183206.5506@leland.Stanford.EDU> Date: 27 Mar 91 18:32:06 GMT References: <1991Mar22.210725.29448@neon.S <1991Mar25.220525.11087@leland.Stanford.EDU> <26714:Mar2602:52:1891@kramden.acf.nyu.edu> Sender: news@leland.Stanford.EDU (Mr News) Organization: AIR, Stanford University Lines: 39 In article , pallas@eng.sun.com (Joseph Pallas) writes: |> |> > 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. 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. Before any Eiffel fans say "Gotcha!" :-), let me go on to say that contravariance isn't really the *problem*, just a (correct) formulation of it: if List[SubT] were a subtype of List[T], some variable v: List[T] could contain either a List[T] or a List[SubT]. However, the statement "v.f(t)" (with t:T) would be unsafe: if t holds a T, and v a List[SubT], we're passing only a T to f, not a SubT as expected (declared). So, again, the problem isn't contravariance, but how you apply it. -Urs ------------------------------------------------------------------------------ Urs Hoelzle hoelzle@cs.stanford.EDU Center for Integrated Systems, CIS 42, Stanford University, Stanford, CA 94305