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.3 required=5.0 tests=BAYES_00,INVALID_MSGID autolearn=no autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 103376,ec4cde5d799065b6 X-Google-Attributes: gid103376,public From: csampson@cod.nosc.mil (Charles H. Sampson) Subject: Re: Coding Standards & GOTO Date: 1997/09/26 Message-ID: <1997Sep26.173917.5001@nosc.mil>#1/1 X-Deja-AN: 275790904 Sender: news@nosc.mil References: <01bcc32e$350b5ba0$6409868b@gateway> <3426B51E.7296@lmco.com> Organization: Computer Sciences Corporation Newsgroups: comp.lang.ada Date: 1997-09-26T00:00:00+00:00 List-Id: In article , Matthew Heaney wrote (among other things): > >And what's wrong with objects in the spec? Have you read Ada.Text_IO >lately? Again, this calls for guidelines for when to declare an object in >the spec, and when not to. For example, when implementing a subsystem, >then an object shared among packages in the same subsystem can be declared >in the spec of a private package. > >Also, a well-known object, used throughout the system, can be declared in a >spec: > >package Targets.Objects is > > type Target_Array is array (Positive range 1 .. 20) of Target; > > The_Targets : Target_Array; > >end; > >What's wrong with that? While I agree your basic premise that absolute rules are never correct (including this one), what's wrong with this example is that it locks anybody who uses this package into the design decision that tar- gets will be stored in an array. Change that to a linked list and you've got a major code modification job. This is exactly what Parnas taught us not to do in 1972. While I share your aversion to absolute rules, I almost never have objects in the visible part of package specs. The exceptions seem to almost al- ways be Boolean. Charlie -- ****** If my user name appears as "csampson", remove the 'c' to get my correct e-mail address.