Re: Need advice re package organization.

["Randy Brukardt" <randy@rrsoftware.com>]

"Warren W. Gay VE3WWG" <ve3wwg@cogeco.ca> wrote in message
news:clWVa.4191$mv6.741217@news20.bellglobal.com...
> The problem occurs in the private child package (IMO) because
> you want to derive new objects from parent tagged records. The
> danger that develops is that the child package's body code may
> monkey with things in the parent object that you don't want it
> to (this is lack of information hiding).
>
> However, you can fix the object visibility by making it a non
> child package (just another package using the first). However,
> the problem then becomes that you lose access to other types
> and definitions that are in the other package's private part.
>
> So in my mind, there still exists a short-coming OO wise
> in the visibility rules for objects: it needs a way to
> mark parts of a tagged object as "off limits" for the child
> package, which always enjoys full visibility of the parent
> package's tagged record (object).

You can do this by deferring the contents of the tagged type to the body:

     type My_Type_Contents;
     type My_Type_Contents_Access is access all My_Type_Contents;
     type My_Type is tagged record
          Contents : My_Type_Contents_Access;
     end record;

Then no child can see the contents. Claw uses this technique in some cases.
The body contains the full declaration of My_Type_Contents.

This technique works best when the tagged type is Controlled (since the vast
majority of tagged types ought to be controlled, this is not a real
restriction). Then the Initialize routine can allocate the contents, and the
Finalize can free it. The only remaining danger would be someone assigning a
Null into the Contents access, which is a lot less likely than fiddling with
components.

               Randy.