Re: Need advice re package organization.

[Dmitry A. Kazakov <mailbox@dmitry-kazakov.de>]

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.

What I would like to have

1. multiple parents;

2. an ability to choose which members are public and which are not
(presently one needs a two-stage deriving);

3. an ability to have public read-only members with full access in the
private part;

4. a finer control over overridings (a vast theme).

---
Regards,
Dmitry Kazakov
www.dmitry-kazakov.de