Re: Need advice re package organization.

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

"Warren W. Gay VE3WWG" <ve3wwg@cogeco.ca> wrote in message
news:AVbWa.1379$qN3.184689@news20.bellglobal.com...
> > But if you do not want to see private things, then the package should
> > not be a child.
>
> You are missing the point. If the package is not a child package,
> then this new package loses all access to the other private
> types declared in the private section. Sometimes you need to have
> things both ways.

That sounds like a very muddled design. Previously you said:

> Irregardless, there is _NO_ way whatsoever to identify
> Ada95 OO members/primitives as "protected" (ie. accessable
> by derived code, but not to the end clients of the object).

Which is false: The derived code goes in children (if they need the
visibility), the end clients do not. If your end clients are in children,
you've got design problems.

What you're asking for is a fine-grained visibility control that does not
exist anywhere in Ada. For instance, when you say "with", you get the whole
package; there is no option to just get part of it. When you say "use", you
get the whole package; there is no option to just get individual items.

Some have claimed this is a fault, but in any case you'd have a very
different language if you had those sorts of capabilities. One of the
advantages of the current scheme is that it works very well for
programming-in-the-large: a change to a distant unit can only change units
in which it is directly referenced.

We've found in working on "limited with" that this property is a lot harder
to maintain if you have views of the same entity with different properties
that can clash (if you have a diamond-shaped with pattern). This is a
property that we should not be willing to give up for Ada.

Anyway, I think you will have to make a complete proposal so we can tear it
to shreds. :-) Claiming that there is some lack of visibility control
without showing how that control could be defined and would be used in
practice is not very compelling.

                         Randy.