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,45abc3b718b20aa3 X-Google-Attributes: gid103376,public From: adam@irvine.com (Adam Beneschan) Subject: Re: Two ideas for the next Ada standard Date: 1996/09/04 Message-ID: <50k41q$j1m@krusty.irvine.com>#1/1 X-Deja-AN: 178522393 references: organization: /z/news/newsctl/organization newsgroups: comp.lang.ada Date: 1996-09-04T00:00:00+00:00 List-Id: In article dewar@cs.nyu.edu (Robert Dewar) writes: >Laurent says >" My point was that "private part = primarily an efficiency hack" is >technically true in Ada 83 (since we can remove it, but I'm not >suggesting it should have been done ;-), but false in Ada 95 where a >private part has an important semantic role in visibility issues." > >Now that I do not understand. The point of private parts in both Ada 83 >and Ada 95 is to control visibility. If you remove private parts in >Ada 83, you lose the visibility control, the same is true in ada 95 >(child units see the spec as well!) I think we're getting off topic here. When we were originally talking about removing private parts in Ada 83, we were discussing moving the full "private" definitions to the BODY, not leaving them visible in the spec. This is equivalent in terms of visibility (in Ada 83, that is). The "efficiency hack" referred to the problem that it's harder to get the compiler to generate code when the full type definitions are in the package body; presumably this is why they were moved to the spec and put into a private part. On an unrelated topic, I wonder whether the language designers would have come up with a different terminology if they knew we were going to have these discussions? All this talk about "removing private parts" is generating some disturbing visuals . . . -- Adam