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: 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: dewar@merv.cs.nyu.edu (Robert Dewar) Subject: Re: Interface/Implementation (was Re: Design by Contract) Date: 1997/09/07 Message-ID: X-Deja-AN: 270501483 References: <340C85CE.6F42@link.com> Organization: New York University Newsgroups: comp.object,comp.software-eng,comp.lang.ada,comp.lang.eiffel Date: 1997-09-07T00:00:00+00:00 List-Id: Don says <> No, and neither does the Ada 83 standard in this context, so your comment about finding this annoying is simply confused. We are talking about the order in the body of entities declared in the spec. Clearly these have all been previously declared, so the order of subprogram bodies in the body of the package is completely free, I have no idea what you are talking about. If you see a different ordering in the spec than in the body, it is not because of "compilation dependencies", it is because the programmer thinks this is a good idea. Yes, I know, language designers are partially in the business of telling the programmer that they know better than the programmer does and imposing restrictions, but this one seems inappropriate. What I often find quite appropriate in Ada is to group the specs in a logical order in the package spec, since this is often browsed to get an idea of the facilities offered by a package by humans, and an appropriate logical order can help this browsing. On the other hand, you never need to browse the body as a client of the package, so the logical ordering requirement for such browsing does not apply. The two files are viewed VERY differently in an Ada environment, not only will different people touch them, but different people will look at them, and the client of a package should almost never be looking inside the body -- if they need to, it shows something is wrong with the spec. Incidentally the separate files aid this goal. An Ada programmer expects to find everything they need in one file, and is definitely annoyed, and knows that there is a bug, if they have to go and look at the body. If you put things in one file, even a single file with different views, it is far too easy for programmers to get in the habit of looking at this file without going though the restricted interface view, and thus not to be sensitive enough to enforcing the separation. Yes, tools could make this harder, but in practice, not everyone is using such tools, and it is all too easy for a client to easily browse the implementation. Going back to the ordering issue, in the body, I usually prefer to arrange the subprograms in alphabetical order, because this is easier for reference purposes for the implementor who needs to go to a particular body to debug or otherwise fiddle around. That's the *crucial* difference between the spec and the body, the spec gets browsed as a whole, the body never does. I quite see how Eiffel programmes, or other programmers not used to this strong separation would not see the benefit of being able to organize the two objects differently, you do not miss what you do not have. One of the most widespread weaknesses, even among experienced professional programmers, is the inability to comprehend the importance of separating specification from implementation. Note tha the entire "comments are useless, my code is self documenting" view is fundamentally at odds with this basic requirement of separation. Yes, you can separate effectively in any language if you work hard enough (the equivalent of a separate spec can be created entirely by commenting even in a language like COBOL or BASIC with absoslutely NO avbstraction capability of this sort), but in practice, a language like Ada where this separation is very strong will encourage more programmers to understand the importance of the separation. In the Ada world, absolutely everyone understands that you should be able to use a package only looking at its spec and not its body, and the fact that the spec can be handled separatly as a coherent compilable entity is one of the most important aspects of Ada, since it leads even inexperienced not very competent programmers to fully grasp the importance of the separation of spec and body. <> Though this technical point is completely irrelevant to the main thread of discussoin here, if you are saying that you should be able to use entities before they are declared. I strongly disagree. Sure my compiler can make multiple passes through a source document, but as a human reading the document, I prefer not to. There is a reason why we arrange text books, and other materials not to have forward references (such as mentioning a character in a novel before introducing them). Programs benefit in the same way from a basically linear approach, in which overall understanding can be obtaineed in a single linear pass. But as I noted, this point is totally irrelevant to the discussion, since of course the spec appears "before" the body, so there are no ordering relationships imposed on the entities in the body that correspond to those in the spec in any case.