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: 103376,d927b7ea9b65580a X-Google-Attributes: gid103376,public X-Google-ArrivalTime: 2002-11-12 09:39:31 PST Path: archiver1.google.com!news1.google.com!newsfeed.stanford.edu!logbridge.uoregon.edu!hammer.uoregon.edu!skates!not-for-mail From: Stephen Leake Newsgroups: comp.lang.ada Subject: Re: Style: always declare subrountines? Date: 12 Nov 2002 12:31:30 -0500 Organization: NASA Goddard Space Flight Center (skates.gsfc.nasa.gov) Message-ID: References: <3dccc023$0$304$bed64819@news.gradwell.net> NNTP-Posting-Host: anarres.gsfc.nasa.gov Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: skates.gsfc.nasa.gov 1037122945 27374 128.183.235.92 (12 Nov 2002 17:42:25 GMT) X-Complaints-To: usenet@news.gsfc.nasa.gov NNTP-Posting-Date: 12 Nov 2002 17:42:25 GMT User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.2 Xref: archiver1.google.com comp.lang.ada:30768 Date: 2002-11-12T17:42:25+00:00 List-Id: porton@ex-code.com (Victor Porton) writes: > How do you consider this: > > If one would always declare every subrountine of a package body in the > specification (in the public or in the private part) Far too restrictive. There are many times when it is good to implement many small subprograms in the body, that simply do not belong in the spec, public or private. Other children of the package should _not_ see them! This is especially true when the body requires packages that the spec does not. Moving subprogram declarations to the spec then requires moving the package "with" clauses to the spec. This is sometimes illegal, due to circularity or private children issues. > this excludes the possibility that one may mistakedly create an > internal subrountine with the same specification as a not yet > implemented public procedure and forget to implement this public > procedure and so get wrong program behavior. If the public interface is not present, you'll get a compilation error, not "wrong behavior". Hmm, I guess you can get "wrong behavior" if you forgot to overload or override a subprogram in the spec, and thus get the "parent" subprogram. Is that what you are talking about? In that case, you can sometimes make the parent procedure abstract > Stylistic checkers for always declaring in package specification? As others have said, there is no substitute for a good design process. -- -- Stephe