From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me X-Spam-Level: * X-Spam-Status: No, score=1.0 required=5.0 tests=BAYES_00,INVALID_MSGID, PP_MIME_FAKE_ASCII_TEXT,REPLYTO_WITHOUT_TO_CC autolearn=no autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII X-Google-Thread: 103376,be374b0c80915daf X-Google-Attributes: gid103376,public X-Google-Thread: fac41,d04de3979117f1b2 X-Google-Attributes: gidfac41,public X-Google-Thread: f79bb,be374b0c80915daf X-Google-Attributes: gidf79bb,public From: Graham Perkins Subject: Re: covariance and parameter modes (was: Re: Instantiating Generic Object) Date: 1997/11/14 Message-ID: <346C65D1.5C7E@dmu.ac.uk>#1/1 X-Deja-AN: 290349986 References: <646g1b$avs@solaria.cc.gatech.edu> <3466EBB8.61AE@stratus.com> <3468E43B.7BCFFF2C@munich.netsurf.de> <346B1E1F.25F3@hello.confusion.nl> Organization: De Montfort University Milton Keynes Reply-To: gperkins@dmu.ac.uk Newsgroups: comp.lang.eiffel,comp.lang.sather,comp.lang.ada Date: 1997-11-14T00:00:00+00:00 List-Id: Karel Th�nissen wrote: > For in-parameters, contravariance is the typesafe approach. For > out-parameters, and hence function results, covariance is the typesafe > approach. For in-out-parameters, being a combination of the two, only > 'invariance' is typesafe. ancestor--> whole_sqrt( n:NATURAL ) : NATURAL descendant--> whole_sqrt( n:INTEGER ) : INTEGER contravariant in-parameter for type safety. But it aint semantically safe, eg sqrt(-3) contravariant "out" result not safe, but it could well make more sense for programmer who doesn't want his functions creating mixed-mode arithmetic. DISCLAIMER DISCLAIMER DISCLAIMER DISCLAIMER this may not be a good example, please let's not go down a long thread about how dreadful I am at designing numerical libraries! My point is this: foolproof type safety of any language feature often has to be obtained at the cost of some expressive power. In some casess it may be better to take a more pragmatic approach and let programmers do things that make sense in terms of the domain they are working with. Eiffel's covariance originally gave high flexibility and created horrible (but solvable) validity problem. New CAT rules restrict it a little and make validity much simpler (class rather than system level). It's a trade-off and there obviously isn't one correct answer. --------- For domain argument concerning parameter/result variance, simply think of an object with local container and exported "put" and "get" methods. You put something into the object, or you take it out. Now if you allow variance at all, a descendant object should allow you to put and get something else. Should the "something else" be a descendant or ancestor of "something"? I don't care. Whichever rule you make, you end up having the *same* variance policy for in-parameters and out-results. --------- [Roger, was that a good disguise of my cow, herbivore, food, grass, example that we all got heartily sick of? ]