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,92471489ebbc99c6 X-Google-Attributes: gid103376,public From: stt@houdini.camb.inmet.com (Tucker Taft) Subject: Re: Y2K Issues Date: 1998/10/29 Message-ID: #1/1 X-Deja-AN: 406412374 Sender: news@inmet.camb.inmet.com (USENET news) X-Nntp-Posting-Host: houdini.camb.inmet.com References: <71aejn$ped$1@nnrp1.dejanews.com> Organization: Intermetrics, Inc. Newsgroups: comp.lang.ada Date: 1998-10-29T00:00:00+00:00 List-Id: dewar@gnat.com wrote: : In article , : stt@houdini.camb.inmet.com (Tucker Taft) wrote: : > Users *are* allowed to add grandchildren to package Ada. : > They may not add "direct" children to package Ada (nor may vendors, : > for that matter) -- see RM95 A.2(4). : I find this a very odd claim. In RM A(4) we have : Implementation Permissions : 4 The implementation may restrict the replacement of language-defined : compilation units. The implementation may restrict children of : language-defined library units (other than Standard). : ... But : the paragraph I quoted above clearly allows a compiler to forbid the addition : of children of packages in Ada unless I am really missing something! Good point, Robert. So, some compilers might allow user-defined grandchildren of Ada, while others might not, so it is not a portable capability. Even if it were allowed by all relevant compilers, as Robert points out below, the actual code of the (grand)child would probably not be portable, since presumably it would depend on implementation-specific private types. (FWIW, from my point of view, the fact that the code for such grand-children is likely to be implementation-specific doesn't seem like enough of a reason to disallow them, since the whole point may be to provide a stable interface to some additional functionality via a grand-child, recognizing that the implementation of the functionality may need to be revised when porting to a new compiler or new release. Clearly the "caveat emptor" is critical here.) : Robert Dewar : Ada Core Technologies : P.S. Why don't we want customers adding grandchildren of Ada -- simple, they : would potentially depend on internal private parts of the implementation of : these packages which we feel free to change without notice at any time! -- -Tucker Taft stt@inmet.com http://www.inmet.com/~stt/ Intermetrics, Inc. Burlington, MA USA An AverStar Company