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: 103376,3d3f20d31be1c33a X-Google-Attributes: gid103376,public X-Google-Thread: 1108a1,2c6139ce13be9980 X-Google-Attributes: gid1108a1,public From: Nick Leaton Subject: Re: Interface/Implementation (was Re: Design by Contract) Date: 1997/09/02 Message-ID: <340BC9A0.9D0A7261@calfp.co.uk>#1/1 X-Deja-AN: 269504120 References: <01bcb389$24f579d0$1c10d30a@ntwneil> Reply-To: nickle@pauillac X-NNTP-Posting-Host: calfp.demon.co.uk [158.152.70.168] Newsgroups: comp.object,comp.software-eng,comp.lang.ada,comp.lang.eiffel Date: 1997-09-02T00:00:00+00:00 List-Id: Matt Kennel (Remove 'NOSPAM' to reply) wrote: > > On Thu, 28 Aug 1997 14:53:19 GMT, Tucker Taft > :The hand-written Ada package spec (or even C header) remains a far > :superior interface document for a given abstraction than is anything > :I have seen extracted by a tool. The result of extraction by a tool > :typically ends up getting some but not all of the comments, and the > :various operations are not presented in necessarily a helpful order, > :or with any useful higher-level organization. > : > :Basically, the extraction tool tends to tell you what an abstraction > :"is" or "does", rather than what it is supposed to do, and why. > :When trying to decide whether a given implementation is correct, > :without that separate human-written spec, it is much harder to evaluate. > :One is simply stuck trying to evaluate internal consistency, rather > :than consistency against a separate human-written spec. > > I agree that these are important, but I don't see how Eiffel abstract > classes are inadequate for this purpose. The reason lies with how Eiffel handles comments and its support for pre and post conditions and class invariants. In Eiffel not all comments are equal. If you look at the syntax of the language although all comments have the same appearance '--' and all characters to the end of the line, comments appear in the syntax. Comments appearing in certain places in the code, for example, just after the class name are documentation comments and appear in the 'short form'. (The spec). You also have assertions that closely correspond to the spec, saying what the feature will do for you if you satisfy the precondition. In other words a lot of your spec ends up in you classes. As to ordering, well you should be ordering your code, as you should be ordering your spec. -- Nick Eiffel - Possibly the best language in the world - unless proven otherwise.