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 X-Google-Thread: f43e6,2c6139ce13be9980 X-Google-Attributes: gidf43e6,public X-Google-Thread: 1108a1,2c6139ce13be9980 X-Google-Attributes: gid1108a1,public From: nospam@thanks.com.au (Don Harrison) Subject: Re: Interface/Implementation (was Re: Design by Contract) Date: 1997/09/10 Message-ID: #1/1 X-Deja-AN: 271200460 Sender: news@syd.csa.com.au X-Nntp-Posting-Host: dev50 References: Organization: CSC Australia, Sydney Reply-To: nospam@thanks.com.au Newsgroups: comp.object,comp.software-eng,comp.lang.ada,comp.lang.eiffel Date: 1997-09-10T00:00:00+00:00 List-Id: 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. This is why Eiffel classes usually have exported features at the top and private ones at the bottom. You might expect to see primary ordering on the basis of functionality and secondary ordering from high level to low level. Due to Ada's dependency ordering, I often find myself reading package bodies in reverse order. 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. 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. This problem doesn't arise in Eiffel because ordering is free. 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. For example, type a_rec; -- pre-declaration type a_rec_ptr is access a_rec; type a_rec is record next: a_rec_ptr; end record; and procedure do_d; -- pre-declaration procedure do_c is begin do_d; end; procedure do_d is begin do_c; end; While not a huge burden, it's inelegant and un-necessary, IMO. Again, this issue doesn't arise in Eiffel. :This is not unlike saying that "strong typing" is a helpful limitation, :but a limitation nonetheless. I think this is a poor analogy. While strong typing delivers some obvious benefits, I don't think the same can be said of forced dependency ordering. Don. (Reverse to reply) =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Don Harrison au.com.csa.syd@donh