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,d10596e187e90822 X-Google-Attributes: gid103376,public From: Richard D Riehle Subject: Re: Private Children Date: 1999/06/22 Message-ID: <7koepa$66q@dfw-ixnews9.ix.netcom.com>#1/1 X-Deja-AN: 492573060 References: <7klja3$c0p$1@nnrp1.deja.com> <376E70A5.F77E558D@averstar.com> <376E9EEB.322A3F39@averstar.com> <7kmoe4$o83@dfw-ixnews15.ix.netcom.com> Organization: Netcom X-NETCOM-Date: Tue Jun 22 11:48:42 AM CDT 1999 Newsgroups: comp.lang.ada Date: 1999-06-22T11:48:42-05:00 List-Id: In article , dale@cs.rmit.edu.au (Dale Stanbrough) wrote: >Richard D Riehle wrote: > > package P.Hidden_Level.Public_Level is > -- code deleted > package body P.Hidden_Level.Public_Level is -- code deleted > >It's still a bit ordinary though. The services offered in the >public level can't rely on abstractions advertised in the private >section, which I see as the major failure of this model. I see it differently -- not as a failure but as an opportunity for powerful design of abstractions. It might be the case that we want to make some specifications available for type derivation with a hierarchy of types, T'Class, as an implementation detail, but hide those implementation details from the final user of some public class. I wonder if this is one way for an Ada designer to differentiate implementation inheritance from interface inheritance. The type exported from the public package will be a pure interface, a contract with some client. The abstractions in the parent packages, those with no public specifications, can safely focus on implementation inheritance without the risk that the client will inadvertantly enter the hierarchy at the wrong place. Richard Riehle richard@adaworks.com http://www.adaworks.com