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,e977cd3ab4e49fef X-Google-Attributes: gid103376,public From: Ken Garlington Subject: Re: Question about record rep spec placement Date: 1997/01/17 Message-ID: <32E02DB1.6E06@lmtas.lmco.com>#1/1 X-Deja-AN: 210554425 references: <32DF9F55.7EA3@lmtas.lmco.com> <5bof0o$q0i@zeus.orl.mmc.com> content-type: text/plain; charset=us-ascii organization: Lockheed Martin Tactical Aircraft Systems mime-version: 1.0 newsgroups: comp.lang.ada x-mailer: Mozilla 3.01 (Win95; U) Date: 1997-01-17T00:00:00+00:00 List-Id: Robert A Duff wrote: > > parts. However, because of the freezing rules, it is not always > possible to do that. Therefore, my style is to put the rep clause right > after the type. This makes various changes less painful -- e.g. suppose > you want to add something into the visible part that freezes the type. > You'll have to move the rep clause to do that. I guess this depends upon whether being unable to put the rep spec in the private area due to freezing rules is a "pathological" case (as has been described previously) or will occur relatively often. If the former, then a comment should do for those cases where the rep spec can't be placed in the private area. If the latter, then I think this potential incompatibility from Ada83 to Ada should be more widely advertised. I don't know which is the case; does anyone has real-world experience they could share? > Besides, a style rule > that says "Put this info in the private part when possible, but > otherwise put it in the visible part" seems kludgy to me -- knowing that > rule, I have no idea what it means that a rep clause is in the visible > part. Is it because clients are supposed to take advantage of it? Or > is it merely because there happens to be some freezing point of the > type, and the programmer couldn't put the rep clause in the private > part. This was even more of a problem prior to the advent of child packages. Was something outside the private part because the client needed it, or because some support package needed it. I think the style rule would be better stated as "If something is likely to change, or if the user should otherwise not depend on it, don't put it in the public part of the spec." (That's basically the way it's worded in SPC ADARTS, which we use.) Even if that rule can't always be followed, I think it's still a good rule. Assuming Ada will let you follow that rule most of the time (and, at least in my Ada83 experience, it would), then the exceptions should be relatively small and can be handled via comments. If you can't follow that rule most of the time, then "programming by contract" isn't possible and we might as well all use Eiffel :) > IMHO the freezing/forcing rules are a serious flaw in the language. > > > 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. "for type T use private"? Is that legal Ada? I've never used that before! I wouldn't say it as "Tell the user... to look for further specifics about T's representation elsewhere in the package." I would say "Tell the user... if he uses information gleaned outside the visible part of the package spec, he gets what he deserves." Basically, a higher-level abstraction of "using Unchecked_Conversion is both powerful and potentially dangerous." BTW, I can think of some cases where a rep spec might be OK to make public: A size clause, perhaps, for packages supporting system programming, or a record layout that conforms to some stable standard (assuming you can write it portably, or know it won't be ported). -- LMTAS - The Fighter Enterprise - "Our Brand Means Quality" For job listings, other info: http://www.lmtas.com or http://www.lmco.com