Re: Need advice re package organization.

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

Dmitry A. Kazakov wrote:
> On Tue, 29 Jul 2003 13:18:29 -0400, "Warren W. Gay VE3WWG"
> <ve3wwg@cogeco.ca> wrote:
>>Dmitry A. Kazakov wrote:
>>
>>>On Sun, 27 Jul 2003 18:02:08 -0400, "Warren W. Gay VE3WWG"
>>><ve3wwg@cogeco.ca> wrote:
>>>
>>>>Robert I. Eachus" <rieachus@attbi.com> wrote in message news:3F22F9E9.3040307@attbi.com...
>>>>
>>>>>Warren W. Gay VE3WWG wrote:
>>>>>
>>>>>>[As a side note, I sometimes wonder if an enhancement to the Ada0Y
>>>>>>language might be to be able to specify a limited visibility of a
>>>>>>parent package's object's internals (a la not "protected" type in
>>>>>>C++). A protected class in C++ allows derived code to mess with the
>>>>>>internals, whereas normally the parent object's elements are a
>>>>>>black box. Use of limited visibility helps to reduce code coupling.]
>>>>>
>>>>>Actually, that is what a private child package is for.  It allows you to
>>>>>move all of the "useful" internals out of a package body to a place
>>>>>where the body and all the child packages can access them.
>>>>
>>>>Actually, what I had in mind was the object visibility here (not
>>>>package visibility). When deriving from existing tagged records, there
>>>>is no way to limit the visibility of the parent object's members (a
>>>>la "protected" in C++/Java). A derived object can freely mess with any
>>>>tagged record's members, as it sees fit. Information hiding
>>>>and reduced coupling practices suggests that this is not the safest
>>>>route (best to use the existing parent object methods to mess with
>>>>the "parent members").
>>>
>>>I do not know whether there is a statistics regarding use protected
>>>vs. private, but I think that most C++ programmers just stick to
>>>public vs. not. Burden of decision is too heavy for many.
...
> Comparing C++ with Ada, we could say that Ada's "private" is rather
> C++'s "protected". Then Ada has, and C++ lacks, an ability to define
> subroutines with full access to members in the package body, without
> any specification changing. 

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

> Such subroutines could be viewed as an
> equivalent to C++'s "private methods". What Ada does not have are
> private data members in C++ sense. So we have:
> 
> protected in C++ <--> private in Ada
> private method <--> a subroutine in the body [a FAT plus to Ada ]
> private member  <--> missing [a minus]

I think you need to add a dimension to this "chart", because
there are multiple (at least 2) views:

   1. simple client view
   2. a _normal_ child package view

   (a _private_ child's view is the same I think, but if not, this
    is a 3rd).

The problem I am trying to address, is #2. The child package sees
all, even when you don't want it to.

> From my point of view, Ada's model is clearer and more consitent with
> separate compilation / development model. Private, in C++ sense,
> things should actually never appear in the specification.

Well, one could argue that the private parts of a specification
should never be seen by clients (particularly for libraries where
body code is not provided). However, there are obviously practical
compiler reasons for including those things ;-)

One other raod a compiled language like Ada could have taken,
is to compile an intermediate file for those parts of a spec
that are required by the compiler, but should not be seen by
the client. But this has other practical problems, I suspect.

> I remember, Robert Duff, proposed a way to hide everything really
> *private* in the bodies. This would be IMO a right thing.

A child package often needs types and other constants from the
parent package, but "wants" the safety of not dabbling with the
parent object's internals.

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