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: 1108a1,2c6139ce13be9980 X-Google-Attributes: gid1108a1,public X-Google-Thread: 103376,3d3f20d31be1c33a X-Google-Attributes: gid103376,public X-Google-Thread: f43e6,2c6139ce13be9980 X-Google-Attributes: gidf43e6,public From: Samuel Mize Subject: Re: Interface/Implementation (was Re: Design by Contract) Date: 1997/09/10 Message-ID: <3416CA7D.50A@link.com>#1/1 X-Deja-AN: 271306206 References: Reply-To: smize@link.com Organization: Hughes Training Inc. Newsgroups: comp.object,comp.software-eng,comp.lang.ada,comp.lang.eiffel Date: 1997-09-10T00:00:00+00:00 List-Id: [reformatted for line length] Don Harrison wrote: > > Matthew Heaney wrote: > > :In article , doylep@ecf.toronto.edu > :(Patrick Doyle) wrote: > : > :>>The Eiffel camp seems to think that dependency order is a > :>>limitation, but it was a deliberate decision by Ada's designers. > :>>As an Ada programmer, I haven't found it to be a limitation at > :>>all; in fact, I find it quite helpful, exactly as the designers > :>>imagined it would be. > > That's interesting because I find it a hinderance more than a help for > a number of reasons: > > 1) The most important reason is that compulsory backward references > force the developer to order everything (apart from things defined > in the spec) from low level to high level. This is the exact > opposite of what a human reader needs to comprehend the body in a > linear top-down pass. It's far easier for them if high level stuff > is declared first and low level implementation detail progressively > lower down. That way, they can readily grasp the high level picture > at a more abstract level and, if they require more detail, they > can read on. I'm rather an Ada bigot, but you have convinced me that, if people were reading large packages or procedures as linear text, this would be a good approach, perhaps even a better approach. As several people (including Don) have pointed out, if you try to read an Ada unit with a lot of sub-procedures, you wind up reading it from the end backward. As nobody has yet pointed out, you're not going to read and understand this large a code artifact in one pass anyway, so the ordering is largely irrelevant. You need to be able to FIND referred-to elements, but it neither helps nor hurts that all references are to earlier items (especially when the earlier item may be a forward declaration to a later item). So I would agree that the read-in-one-pass argument in favor of dependency ordering is weak, at best. > 2) It's problematic when an exported feature is removed from the > spec (perhaps because it's erroneously exported) and you have to > re-order the body to accomodate dependencies. You can simply move the procedure specification (the part that appeared in the spec) to the start of the body, with an appropriate comment. >If you're not the author of the body, you have to > work out the particular scheme used and find an appropriate spot > for it. This may not be straighforward and is also likely to cause > a ripple effect because operations the operation itself depends on > may subsequently have to move. I find the trial-and-error nature of > this activity incredibly annoying. If it's a trial-and-error process, then the design isn't correctly structured for this kind of organization, and you definitely SHOULD move the procedure spec to the head of the body. I'm not saying such a design is necessarily BAD. It may be a case where dependency ordering is helpful, so you shouldn't try to use it. I've seen well-designed Ada packages where the body starts by forward-declaring all the internal procedures, so they can use each other. A recursive descent parser might be coded this way. I find it helpful to see, up front, which things are > 3) It's also problematic in the case of mutually recursive types > and operations. You are forced to pre-declare those that are > forward referenced. This is in fact one of the arguments in FAVOR of dependency ordering: it prevents accidental mutual recursion, and documents your intent for maintenance coders. - - - I find that Ada's dependency ordering provides a useful level of organization in many cases, and that it is helpful to have forward declarations as an explicit indication that this ordering rule is being abandoned. However, that may just be because I'm used to it. Certainly you can order your declarations this way, if it improves clarity, in a language that doesn't require it. Sam Mize