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: 103376,e977cd3ab4e49fef X-Google-Attributes: gid103376,public From: rgilbert@polaris.orl.mmc.com (Bob Gilbert) Subject: Re: Question about record rep spec placement Date: 1997/01/17 Message-ID: <5bof0o$q0i@zeus.orl.mmc.com>#1/1 X-Deja-AN: 210479722 references: <32DF9F55.7EA3@lmtas.lmco.com> organization: Lockheed Martin E&M reply-to: rgilbert@polaris.orl.mmc.com newsgroups: comp.lang.ada Date: 1997-01-17T00:00:00+00:00 List-Id: In article <32DF9F55.7EA3@lmtas.lmco.com>, Ken Garlington writes: > Bob Gilbert wrote: > > > > What possible purpose would placing the record rep spec in the > > private section serve when the record is not a private type? > > (1) Indicates to the user of the code that it's not smart to make > assumptions regarding the internal organization of the type Well, I guess there is a readability issue, but it seems like an abuse of the private declaration section. If I were looking at code where this was done, I would question what the user had intended. If you really don't want the user to make assumptions regarding the internals of the type, why not just go ahead and make it a private type? Placing the rep spec of a non-private type in the private section (if allowed) does not communicate any information to the compiler and may confuse the reader. Seems like some judicious use of comments might be in order. > (2) We have a tool that takes Ada code and inserts it into documentation > developing using the Interleaf document processor. It makes keywords > bold, and all of that, and it also has an option to suppress listing the > information in the private section. So, if we don't want details to appear > in our user documentation, we put it in the private section. Okay, but it still seems like a kludge and an abuse to me. That said, I do admit that sometimes having to include rep specs in the same declaration list as the entity it refers to, adds unnecessary verbosity to a package specification where the user would probably have little or no use for the knowledge of the type's representation. It might be useful to somehow identify a type as requiring a rep spec, but be able to provide the details elsewhere (say within the package body, or a representation section that works similar to the private section). Say something like: type T is {whatever}; for type T use private; -- Tell the user and compiler to look for -- further specifics about T's representation -- elsewhere in the package, perhaps even in -- the package body. -Bob