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=0.2 required=5.0 tests=BAYES_00,INVALID_MSGID, REPLYTO_WITHOUT_TO_CC autolearn=no autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: fac41,2c6139ce13be9980 X-Google-Attributes: gidfac41,public X-Google-Thread: f43e6,2c6139ce13be9980 X-Google-Attributes: gidf43e6,public X-Google-Thread: 1108a1,2c6139ce13be9980 X-Google-Attributes: gid1108a1,public X-Google-Thread: 103376,3d3f20d31be1c33a X-Google-Attributes: gid103376,public From: "John G. Volan" Subject: Re: Interface/Implementation (was Re: Design by Contract) Date: 1997/09/04 Message-ID: <340F20A0.49B5@ac3i.dseg.ti.com>#1/1 X-Deja-AN: 269892268 References: Organization: Raytheon TI Systems Reply-To: johnv@ac3i.dseg.ti.com Newsgroups: comp.object,comp.software-eng,comp.lang.ada,comp.lang.eiffel Date: 1997-09-04T00:00:00+00:00 List-Id: Patrick Doyle wrote: > > It's my position (until further enlightenment :-) that abstract/ > deferred classes can do what separate interfaces do, and more, so > why do we need separate interfaces? Well, one problem with using abstract/deferred classes as a simulation for separate interfaces, is that the former might do _too much_. You wind up getting polymorphic dynamic dispatching in situations that don't really call for it. This can result in an unnecessary run-time performance penalty when a given program includes only one concerete implementation class for a given abstract class (unless your programming environment is able to detect and optimize this situation). In Ada, every single package must have a separate spec, so Ada programmers are used to applying this pattern everywhere. But I'd wager that very few Eiffel programmers would consider introducing an abstract parent class for every one of their concrete classes, just to simulate Ada packaging. I'd assume that abstract/deferred classes appear in typical Eiffel programs just as frequently as abstract tagged types do in Ada95 programs, and that they typically serve the same role: implementing generalization/specialization hierarchies. So I don't see abstract classes as a very good mapping for Ada package specs, and I agree with those who compare Ada specs to Eiffel short forms. One thing I'm curious about: Can an Eiffel environment tell the difference between an interface modification and an implementation modification? Suppose a programmer edits a class text and only makes changes to its implementation (like changing a few statements in the body of a method) but doesn't make any interface changes (like changing the number and/or types of the method arguments). Semantically, an implementation change shouldn't obsolete the compilation of any client that only depends on the class interface. Will a typical Eiffel IDE be able to distinguish this as an implementation-only change, or will it force the recompilation of all client classes? Conversely, suppose you do make an interface change. Will the IDE detect this and require that all client classes be recompiled? Or is it possible in Eiffel to generate an incorrect executable by linking a class's object code with obsolete client object code? An Ada system can easily distinguish these situations, because the spec and body of a package are separate constructs, typically in separate files. But an Eiffel system would need to be able to take a class text and sift the interface out from the implementation, in order to avoid recompilations when they are not needed but enforce them when they are needed. Do Eiffel systems, in practice, do a good job with this? -- ------------------------------------------------------------------------ Internet.Usenet.Put_Signature (Name => "John G. Volan", Employer => "Raytheon/TI Advanced C3I Systems, San Jose, CA", Work_Email => "jvolan@ti.com", Home_Email => "johnvolan@sprintmail.com", Slogan => "Ada95: World's *FIRST* International-Standard OOPL", Disclaimer => "My employer never defined these opinions, so using " & "them would be totally erroneous...or is that just " & "nondeterministic behavior now? :-) "); ------------------------------------------------------------------------