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,9a4a0b8e5206a866 X-Google-Attributes: gid103376,public From: stt@houdini.camb.inmet.com (Tucker Taft) Subject: Re: Conversion of Access Types Question Date: 1999/01/20 Message-ID: #1/1 X-Deja-AN: 434967224 Sender: news@inmet.camb.inmet.com (USENET news) X-Nntp-Posting-Host: houdini.camb.inmet.com References: Organization: Intermetrics, Inc. Newsgroups: comp.lang.ada Date: 1999-01-20T00:00:00+00:00 List-Id: Matthew Heaney (matthew_heaney@acm.org) wrote: : ... : And for what benefit was the distinction between general and : pool-specific access types made? ... For what (little ;-) it's worth, the optimizer can do a better job if you stick with pool-specific access types, because fewer things are "killed" when you store through a pool-specific access value. As far as history, I certainly wouldn't "blame" Bob for this one. There was an almost fanatic attention to upward compatibility during the Ada 9X process, and that attention certainly paid off in compatibility. The downside is that there are some things that look "silly" in retrospect, and this is probably one of them. Luckily, there aren't many such places, so if you asked someone to draw a line between Ada 95-only features and Ada 83 features, someone with no experience in Ada 83 would have trouble doing so. Even some of us who used Ada 83 extensively now make the mistake of thinking a given feature was "always" there (like 'Image on real types, or child packages). : Matt -- -Tucker Taft stt@averstar.com http://www.averstar.com/~stt/ Technical Director, Distributed IT Solutions (www.averstar.com/tools) AverStar (formerly Intermetrics, Inc.) Burlington, MA USA