Re: Need advice re package organization.

["Warren W. Gay VE3WWG" <ve3wwg@cogeco.ca>]

Randy Brukardt wrote:
> "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.

That appears to accomplish the end result. However, this
design pays a price in allocating and freeing an additional
[sub]object.

For some designs this would be acceptable, but not where
you have many instances of the object, where the price
of allocate/free is too heavy.

So I think my point still stands: you really cannot "properly"
accomplish what I have set out to do, although you have
illustrated a work-around.

> 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.

Agreed that the risk is lower, but it still exists if you place
the objects (from a library) in the hands of a user.  If you
are supporting that library, this increases risk of servicing
calls that should not be your responsibility.

-- 
Warren W. Gay VE3WWG
http://home.cogeco.ca/~ve3wwg