comp.lang.ada
 help / color / mirror / Atom feed
From: Richard D Riehle <laoXhai@ix.netcom.com>
Subject: Re: Private Children
Date: 1999/06/23
Date: 1999-06-23T12:16:28-05:00	[thread overview]
Message-ID: <7kr4pc$bb9@dfw-ixnews15.ix.netcom.com> (raw)
In-Reply-To: dale-2306991359560001@dale.cs.rmit.edu.au

In article <dale-2306991359560001@dale.cs.rmit.edu.au>,
	dale@cs.rmit.edu.au (Dale Stanbrough) wrote:

>Yes I know that, but I'm not concerned about parent/child packages, but
>about sibling (or rather non lineal descendant) packages/privacy issues.
>
>I think that the current situation forces too much exposure of
>implementation issues that will cause package hierachies to end up 
>a large entagled mess, because we are continually forced to abandon
>internal privacy goals to meet external ones.

The Ada private part is analogous to the C++ protected part.  A
derivation of a C++ class may see the protected part of its parent.
Ada has ways to strengthen the encapsulation if you wish.  Private
packages are one way.  Another useful technique is opaque types.

An opaque type is a type that contains nothing but a reference to
data. This is quite easy using Ada's incomplete type definition.
These can be tagged for extensibility while hiding all the details
within a package body.  Consider,

     package P is
       type T is tagged private;
       -- operations on T
     private 
       type Item;
       type Item_Pointer is access all Item;
       type T is tagged record
          Data : Item_Pointer;  -- a reference to hidden data
       end record;
     end P;

Now T can still be extended, but the implementation of Item
is deferred to the package body.  If you want to be really clever,
you can create a private child package of P where Item is fully
defined in the private specification and with'ed into the body of
P.  This enforces the rule that nothing but a package body rooted
at P can access the public specification of the private child.  
This preserves extensibility within the hierarchy but prevents 
access by any ordinary client.  

This example follows the Modula-2 convention for information 
hiding using opaque types. Note that Modula-3 improves upon this
through reference types that are followed with a reserved word, 
REVEAL,in the IMPLEMENTATION MODULE.  

In the final analysis, though, encapsulation is something like the
lock on a safe that is intended to keep honest people honest. If 
someone is determined to break encapsulation, they will find a way
to do it, even if they have to crack open your package body and
perform "open heart surgery."

Richard Riehle
richard@adaworks.com
http://www.adaworks.com




  reply	other threads:[~1999-06-23  0:00 UTC|newest]

Thread overview: 22+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
1999-06-20  0:00 Private Children Matthew Heaney
1999-06-21  0:00 ` Ted Dennison
1999-06-21  0:00   ` Tucker Taft
1999-06-21  0:00     ` Matthew Heaney
1999-06-21  0:00       ` Tucker Taft
1999-06-22  0:00         ` Richard D Riehle
1999-06-22  0:00           ` Dale Stanbrough
1999-06-22  0:00             ` Richard D Riehle
1999-06-22  0:00             ` Matthew Heaney
1999-06-23  0:00               ` Dale Stanbrough
1999-06-23  0:00                 ` Matthew Heaney
1999-06-23  0:00                   ` Dale Stanbrough
1999-06-23  0:00                     ` Richard D Riehle [this message]
1999-06-23  0:00                       ` Vladimir Olensky
1999-06-23  0:00                         ` Richard D Riehle
1999-06-24  0:00                           ` Hyman Rosen
1999-06-24  0:00                             ` Richard D Riehle
1999-06-23  0:00                       ` John Duncan
1999-06-24  0:00                       ` Dale Stanbrough
1999-06-21  0:00     ` Matthew Heaney
1999-06-25  0:00   ` Robert Dewar
1999-06-21  0:00 ` Dale Stanbrough
replies disabled

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox