Re: Need advice re package organization.

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

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.

Many of these issues are tough to decide up front, particularly
if these are libraries for users to use. However, when I used
C++, I tended to leave protected out (disallowing access to
internal members), until I had a good reason to do otherwise.

While it has been a while since I looked at M$ code, I believe they
use it (or not, depending upon its intended use) displaying some
decision making there.

> What I would like to have
> 
> 1. multiple parents;

This could be useful, no doubt. But it also introduces new
issues but I suppose I would reluctantly endorse MI if pressed
to make a choice.

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

Yes.

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

Yes. Even C++ lacks this. However, one could argue that you should
always provide an "interface" to these, but from a practical level,
I find this a big pain.

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

Certainly an area of discussion. The practical question is whether
things need to be done about the present scheme of things, or not.

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