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: nospam@thanks.com.au (Don Harrison) Subject: Re: Interface/Implementation (was Re: Design by Contract) Date: 1997/09/05 Message-ID: #1/1 X-Deja-AN: 269963316 Sender: news@syd.csa.com.au X-Nntp-Posting-Host: dev50 References: <340F3801.47E5@pseserv3.fw.hac.com> 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-05T00:00:00+00:00 List-Id: W. Wesley Groleau wrote: :> 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. :) First, you didn't answer my question: "Does the Ada95 standard impose dependency-related ordering?" Eiffel has no such dependency ordering - if one operation calls another, you can declare the called operation later in the text. - Anything in an Ada body can see everything in the spec. I didn't say it couldn't. :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. :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".) Okay, if your tools are sophisticated enough to find the operation for you 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? Text editors are what I'm talking about. In particular, 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. :> As Patrick explained, comments are either extracted or ignored on the basis of :> where they appear in the class text. Those in interface-specific parts of the :> text are extracted into the short form. : :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. BTW, how do you "automatically enforce" the existence and content of optional free text? Don. (Reverse to reply) =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Don Harrison au.com.csa.syd@donh