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,3ad42f911d53327e X-Google-Attributes: gid103376,public From: Dale Stanbrough Subject: Re: Object Oreinted Style Date: 2000/03/31 Message-ID: #1/1 X-Deja-AN: 604759125 References: <8bq4hh$psj$1@ssauraac-i-1.production.compuserve.com> <8c21qm$dbl$1@nnrp1.deja.com> X-Trace: 31 Mar 2000 23:53:48 GMT, r1021c-18.ppp.cs.rmit.edu.au Organization: RMIT User-Agent: MT-NewsWatcher/3.0 (PPC) Newsgroups: comp.lang.ada Date: 2000-03-31T00:00:00+00:00 List-Id: Magnus Larsson wrote: > In article , > Dale Stanbrough wrote: > [.....] > > > > Def. child packages "open up" the full view of a parent type declared > > in a parent package, and in this regard invite abuse by preventing > > total encapsulation. > I am by no means an expert in this area, but isn't a "private package" > a solution here? > like : > package Parent is > type Base_Type is.... > ... > end Parent; > private package Parent.Child is > type Derived_type is new Base_type..... > ... > end Parent.Child; > Or have i completly missed the point here? I thought this construct does > exactly this and "closes" any direct access to the child. A private package can still see the full declaration of the type defined in the parent package. This is what i meant by the private type being "opened up" again (this is terminology borrowed from Betrand Meyer really). For example... package Parent is... type Base_Type is tagged private; private type Base_Type is tagged record X : integer; end record; end Parent; package Parent.Child is type Derived_Type is new Base_Type with private; procedure Clear_All_Fields (Item : Derived_Type); private etc. end; In the body of Parent.Child procedure Clear_All_Fields can change the value of the field X, despite it being declared private. Making Parent.Child doesn't prevent this from happening. Private packages are useful, but only to an extent. They prevent compilation coupling (changing a private packages spec will never require the recompilation of a package outside of the hierachy), but fail to provide the sort of support for abstractions that i'ld like to see (the completion of a private type in a public package being derived from a type declared in a private package). I find them frustratingly limiting for this reason. Of course this is in constrast to "private" types inside packages, which do not prevent compilation coupling, but are used to support abstractions! Dale Dale