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: 103376,3d3f20d31be1c33a X-Google-Attributes: gid103376,public X-Google-Thread: 1108a1,2c6139ce13be9980 X-Google-Attributes: gid1108a1,public X-Google-Thread: f43e6,2c6139ce13be9980 X-Google-Attributes: gidf43e6,public From: "John G. Volan" Subject: Re: Separation of IF and Imp: process issue? Date: 1997/09/08 Message-ID: <3414840F.38EC@ac3i.dseg.ti.com>#1/1 X-Deja-AN: 270828913 References: <33E9ADE9.4709@flash.net> 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-08T00:00:00+00:00 List-Id: Patrick Doyle wrote: > > You nkow what? I just thought of an argument against myself here. > Tell me what you think... > > If abstract superclasses are used as interfaces to a class, then > they are optional. Thus, the advantages of tracking spec changes > come only when the programmer *chooses* to track them. Conversely, > *all* spec changes will necessitate alteration of clients, so > arguably *all* classes should have a spec that is somewhat harder > to change. For Eiffel not to enforce this can cause maintenance > troubles down the road. Various Ada folks in this thread have been hinting at this all along, but you've finally tumbled to it. It's not surprising that you'd be conditioned against seeing this, given Eiffel's structure. Nor is it surprising that Ada programmers would fail to make a point of this, as it is something they'd tend to take for granted as "obvious". In Ada, every package must have a separate spec. This is true regardless of whether the class in question has a compelling reason to be abstract ("deferred"). In fact, Ada treats the notions of "class interfaces" (package specs) and "abstract classes" (abstract tagged types) as being totally orthogonal. Indeed, so does Eiffel, if you accept that "package spec" is analogous to "short form" and "abstract tagged type" is analogous to "deferred class." Ada programmers are conditioned to think in terms of establishing the "contract" of a package first, by writing its "interface" (spec), before ever writing a single line of its "implementation" (body). So Ada conditions programmers to adhere to a certain engineering discipline. Ada programmers tend to understand the difference in engineering impact between an interface change and an implementation change, because Ada makes it so obvious. In contrast (in my experience) Eiffel programmers tend to have a harder time even seeing the distinction, given that Eiffel treats the notion of an "interface-only view of a class which describes its contract" as something of an afterthought. (A tad ironic in a language which holds "Design By Contract" as one of its fundamental principles. :-)) Note that I'm not making a value judgment here, just highlighting the difference in emphasis between the two languages, and how they condition programmers to think. I'm sure that Eiffel programmers could point out issues of central importance in Eiffel which tend to be "blind spots" for Ada programmers (e.g., assertions). -- 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? :-) ");