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,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: mheaney@ni.net (Matthew Heaney) Subject: Re: Interface/Implementation (was Re: Design by Contract) Date: 1997/09/05 Message-ID: #1/1 X-Deja-AN: 270005566 References: <340C85CE.6F42@link.com> Organization: Estormza Software Newsgroups: comp.object,comp.software-eng,comp.lang.ada,comp.lang.eiffel Date: 1997-09-05T00:00:00+00:00 List-Id: In article , nospam@thanks.com.au wrote: >IMO, there's no excuse for imposing dependency-related ordering >in an age of multi-pass compilation. Note that many computer scientists, among them Tony Hoare, believe that a measurement of goodness of a language is its ability to be compiled using a single pass. In that tradition, Ada was design so that it could be compiled in a single pass. >Does the Ada95 standard impose dependency-related ordering? Ada was designed in the belief that the source text of a program has two consumers: the human reader, and the Ada compiler. As such, the Ada philosophy is that, when reading the code, one's understanding of the code should only depend on what has come before. So yes, if there is a dependency ordering between two subprogram bodies, then either the dependent body must follow the other, or a specification for the body must preceed the dependent body (subprogram specs can appear in the package body). That there is a dependency-related ordering in Ada (both 83 and 95) is by design; that was the precise intent of Ada's designers. This should be regarded as a Good Thing, because it makes it easier for the human reader to apprehend program text. The same philosophy applies to exits from inside a loop loop exit when end loop; Many programmers think that it's better to use a while loop, ie while not Done loop Done := True; if not Done then end if; end loop; But this is much worse solution, not only because it requires introduction of a flag, but because the human reader has to think about what happens _after_ the flag gets set (does anything else need to get executed prior to the end of the loop?). The poor reader has to study the _entire_ loop. With the exit approach, comprehension only depends on what has come before. -------------------------------------------------------------------- Matthew Heaney Software Development Consultant (818) 985-1271