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.9 required=5.0 tests=BAYES_00 autolearn=ham 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 From: "W. Wesley Groleau x4923" Subject: Re: Interface/Implementation (was Re: Design by Contract) Date: 1997/09/05 Message-ID: <3410309E.6A32@pseserv3.fw.hac.com> X-Deja-AN: 270010404 Sender: usenet@most.fw.hac.com (News Administration) References: <340F3801.47E5@pseserv3.fw.hac.com> X-Nntp-Posting-Host: sparc01 Organization: Hughes Defense Communications Newsgroups: comp.software-eng,comp.lang.ada,comp.lang.eiffel Date: 1997-09-05T00:00:00+00:00 List-Id: > :> IMHO, this is how it should be. One of the annoying things I find with the > :> ability to order operations differently in Ada spec and body is that you > :> see them in a certain order in the spec and may have trouble finding them > :> in the body because they've been re-ordered, often due to compilation > :> dependencies. IMO, there's no excuse for imposing dependency-related ordering > :> in an age of multi-pass compilation. > : > :This seems a little bit 'off' > > Presumably, you mean unpalatable rather than untrue. :) No. I mean both. Untrue because IF the order in the body is changed, it is NOT due to compilation dependencies, AND "in an age of" modern tools (such as 'grep') there no reason for the order to make things hard to find. Unpalatable, because one of Ada's lower priority goals was to make a one-pass compiler possible though not mandatory. > "Does the Ada95 standard impose dependency-related ordering?" To some extent, as stated above. But things declared in a legal order in the spec do not have to have their repetitions in the same order in the body. (And let's not start about repetitions again. We've already established either that this kind of repetition is not a problem, or that arguing about it will accomplish NOTHING.) > - Anything in an Ada body can see everything in the spec. > I didn't say it couldn't. That was the implication (to me) of your complaint about re-ordering. How could it be re-ordered if it is only in the body? > :The spec may be ordered to make things easy for the client to read. > :The body may be ordered to make the implementation easy to understand. > > With Eiffel, you have both and ordering is preserved. What? IF one sequence is better for the spec (short) and another is better for the implementation, how can a single sequence be _best_ for both. However, let's not get into a flame war on this-- ordering is NOT a particularly important matter. > :And with many support tools (such as are nearly mandatory for a large > :product) finding the body depends on the tool, not on the sequence. > > (For the benefit of those who may not know what you mean here, by "body" you > mean an "operation/task/whatever body" (implementation) rather than "package body".) Right. > Okay, if your tools are sophisticated enough to find the operation at least as sophisticated as 'grep', or the 'find' function of most editors (even 'more' has _that_). > then that would help. It's true that in that case, the ordering in the package > body shouldn't matter. However, your comment about making an implementation > easy to understand implies that ordering *is* signigicant. Are you referring > there to more primitive tools such as text editors? No, to more primitive tools like paper. > ... I'm referring to > the situation of scrolling through a package body and expecting to > find operations in the same order as the spec and finding they're > not, and then having to search for them. If you are looking for a particular operation, why are you scrolling through? If you are trying to understand an operation's implementation, you look at it, and if it calls another, you may choose to find that. If your only method for finding it is by remembering its position in the spec, well, then you have an inconvenience. If you are trying to understand the package implementation as a whole, then it is possible that a particular ordering will make that easier. But again, we're arguing VERY small nits. > :Does this mean the accuracy and usefulness of the "spec" depends on > :the coder's compliance with style rules that are not automtically > :enforced? > > Yes, in the same way that the usefulness of comments in Ada programs > depends on adherence to style rules. There is a difference between the usefulness of the "spec" (which I've been led to believe in Eiffel _includes_ certain essential comments), and the usefulness of comments themselves (which in Ada are of secondary value to the actual "code." Put another way, is a short (or short flat) adequate for me to code a client if the coder did not put his comments in the right place or format? In Ada, _IF_ the usefulness demanded comments, and those comments were put in the spec, they would not disappear from the spec if their format was "wrong". I don't say this to slam Eiffel, because I suspect that you did not mean what you appeared to say. -- ---------------------------------------------------------------------- Wes Groleau, Hughes Defense Communications, Fort Wayne, IN USA Senior Software Engineer - AFATDS Tool-smith Wanna-be wwgrol AT pseserv3.fw.hac.com Don't send advertisements to this domain unless asked! All disk space on fw.hac.com hosts belongs to either Hughes Defense Communications or the United States government. Using email to store YOUR advertising on them is trespassing! ----------------------------------------------------------------------