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: 103376,3d3f20d31be1c33a X-Google-Attributes: gid103376,public X-Google-Thread: fac41,2c6139ce13be9980 X-Google-Attributes: gidfac41,public From: "John G. Volan" Subject: Re: Precondition Checking For Ada 0X (Was: Separation of IF and Imp: process issue?) Date: 1997/09/29 Message-ID: <342FFC27.7992@ac3i.dseg.ti.com>#1/1 X-Deja-AN: 276494767 References: Reply-To: johnv@ac3i.dseg.ti.com Organization: Raytheon TI Systems Newsgroups: comp.lang.ada,comp.lang.eiffel Date: 1997-09-29T00:00:00+00:00 List-Id: Don Harrison wrote: > > Matt Heaney wrote: > > :o If you mean list pre and postconditions again in the package body, I > :would say you don't need to bother (but there may be issues about that that > :I haven't considered). > > I would say you *do* need to if you have to duplicate the signature (as you do). I don't see why. Pre- and post-conditions may be part of the "interface" of a method, but I don't see them as part of its "signature", so I don't think they'd need to be repeated in the method body. I define the "signature" of a method to be that portion of its "interface" which is necessary to uniquely identify that method, and distinguish it from all other methods. In languages that don't allow subprogram overloading, such as Smalltalk (and Pascal?), the name of the method by itself is sufficient to identify it. But in a language that does allow overloading, such as Ada95 or C++, the name alone is not enough; you also need the parameter/result type profile. Hence the need to duplicate this profile in both the spec and the body of a subprogram; that way, the compiler can correctly associate a given body with its corresponding spec. Although pre- and post-conditions are important aspects of the interface of a method, and help to define its "contract", neverthelss they do not serve to distinguish or identify the method in any way. In other words, you don't have method "overloadings" that differ only in their assertions (at least not in Eiffel). So, in a hypothetical Ada-with-assertions, I don't see any reason why you'd have to repeat the assertions in the body of a subprogram. (Hmm... suppose preconditions _could_ be used to distinguish different method overloadings that otherwise have identical signatures. This suggests some interesting ideas for a kind of pattern-matching language, where the particular overloading would be dynamically selected based upon which precondition was true at run-time.) -- 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? :-) ");