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: davids@ICSI.Berkeley.EDU (David Petrie Stoutamire) Subject: Re: Eiffel and Java Date: 1996/10/30 Message-ID: <558c14$kv1@agate.berkeley.edu>#1/1 X-Deja-AN: 193253350 references: <550sm2$sn1@buggy.news.easynet.net> organization: International Computer Science Institute, Berkeley, CA, U.S.A. newsgroups: comp.lang.eiffel,comp.lang.ada,comp.lang.sather Date: 1996-10-30T00:00:00+00:00 List-Id: In article , Don Harrison wrote: >Vincent WEBER writes: > >:Sather's contravariant mecanism seem very interesting too, has stronger and >:safer theorical bases... > >Why does Sather use contravariance (apart from the safety issue). You would >expect more specific actions to require more specific parameters. Safety is the primary reason (we claim reason enough!), but it also eliminates runtime checks. (One can still program in a covariant style by placing runtime checks explicitly in the code, but contravariance forces their overhead to be made explicit.) >: 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)? This turns out to be very useful. Sather 1 strictly separates interfaces from implementations; abstract classes ("interfaces") can't have code in them at all. So entirely different mechanisms are at work for code inclusion and subtyping. For example, there is an abstraction in the Sather 1 library called $SET{T} that has methods like "has(element:T):BOOL". One can build a new implementation of sets which conforms to this interface without using any code from it; and that's pretty much what you want, since the implementations may have little in common. If you want some code shared between them, you build a partial class with that code and include from it in both implementations. This way, a third implementation could be built that doesn't use the shared implementation and it doesn't bother anyone. Sather-K makes slightly different choices, allowing code in abstract classes but still allowing code inclusion without subtyping. I view Sather-K inheritance as the natural consequence of merging Sather 1 abstract and partial classes into a single construct. Something similar is possible in Java, where there can be interfaces with no code (and hence no code inclusion from them). Our experience is that the differences between these languages don't affect the code building experience much, but the separation is really missed as soon as one is forced to go back to a language like C++. More information on Sather is available at: http://www.icsi.berkeley.edu/~sather - Dave -- David Stoutamire http://www.icsi.berkeley.edu/~davids