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.3 required=5.0 tests=BAYES_00,INVALID_MSGID autolearn=no autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: fac41,953e1a6689d791f6 X-Google-Attributes: gidfac41,public X-Google-Thread: f79bb,953e1a6689d791f6 X-Google-Attributes: gidf79bb,public X-Google-Thread: 103376,953e1a6689d791f6 X-Google-Attributes: gid103376,public From: mernst@x4u2.desy.de (Matthias Ernst) Subject: Re: Eiffel and Java Date: 1996/11/01 Message-ID: <55crp0$qn9@dscomsa.desy.de>#1/1 X-Deja-AN: 193888023 references: <550sm2$sn1@buggy.news.easynet.net> followup-to: comp.lang.eiffel,comp.lang.ada,comp.lang.sather organization: DESY newsgroups: comp.lang.eiffel,comp.lang.ada,comp.lang.sather Date: 1996-11-01T00:00:00+00:00 List-Id: Don Harrison (donh@syd.csa.com.au) wrote: : Why does Sather use contravariance (apart from the safety issue). You would : expect more specific actions to require more specific parameters. : : Sather also allow sepation between code inclusion and : :subtyping. Is it cleaner, or just more complicated that the universal : :inheritance mecanism ? any comment ?) : What is the purpose of separating interface and implementation inheritance? : When would you need to inherit an implementation without needing it's interface : as well (and vice versa)? All languages that unify inheritance and subtyping enforce that once you inherit from a class you build a subtype. There are several examples (mostly with binary methods and the type Self, SAME, like Current or whatever) that show that it may be the implementation you are interested in but you can't guarantee subtype relationship. Say: class Comparable is "<="(other: Self): Bool is abstract; ">="(other: Self): Bool is other <= self end; ">"(other: Self): Bool is ~(self <= other) end; "<"(other: Self): Bool is other > self end; end; You are likely interested to inherit from this class and only implement "<=" but as we all know subtyping is impossible because of the contravariant position of the Self parameters. When you look at the examples that claim for covariance you will see that many are not interested in subtyping, i.e. subsumption, but gather advantage only from code reuse. There are already many publications about this topic, you may want to search for 'binary methods', 'inheritance is not subtyping', 'type matching', 'F-bounded subtyping' and so on. Look for Kim Bruce, Cardelli, Castagna and many more. As far as I understand it correctly, it is about what Eiffel's new typechecking rules with respect to 'polymorphic catcalls' express: 'If it serves your purpose you may, while inheriting, change parameters or variable types or access rules in an incompatible (i.e. subtype breaking) way. But if you try to use subsumption I (the typechecker) will catch you, requiring programm data flow analysis.' Sather says: 'You may change what you want when inheriting since for subsumption you must separately obey the subtype relation that I can check locally.' which I like better. One should not forget that Sather's rules also have disadvantages. Because of the freedom you have it's nearly impossible to check routines once in the superclass and then inherit them unchecked. The Sather compiler must recheck every inherited routine in the context of its new class. -- Matthias