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

I think you're mis-reading me here.

I am concerned with being able to write a child package which
derives a new type (object) from the parent package. Because
the child package enjoys full visibility (a good thing for the
parent's private types I need), this child package _ALSO_
has full visibility to the tagged objects defined in the private
part of the parent (this is normally a good thing).

BUT, I want, in many cases, to restrict access to members/primitives
of the parent tagged type.

Why is this so difficult to describe/understand? Let's use C++
terms then:

Take the C++ concept of a "private" member, and apply it to a
child package, but, having the child package not be able to
tamper with private members (ie. these members are not public,
and not protected using C++ terms).

Conversely:

Take a C++ class member, declare members "protected" so only deriving
code has visibility; but not the end client code (application code).

> What you're asking for is a fine-grained visibility control that does not
> exist anywhere in Ada. 

YES!  And precisely my point.  It _does_ not exist in Ada.

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

All I ever was suggesting was that some further discussion
might be worthwhile, particularly in light of 200y changes.

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

I fail to see how the implementation of "protected" would change
this "nature" for programming in the large.

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

I was never proposing, nor interested in selective uses of private
parts of a package. I am only speaking of tagged record views here,
but it has application to child packages, because of their special
status.

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

Randy, I don't think you're being entirely fair about this discussion.

We're talking about protected access of classes (C++). I am not saying
Ada has to have it, but merely pointing out that I find it "missing"
WRT to having used C++ in a previous life. IOW, I find a need/wish
for it, on the principle that "information hiding" is safer, which is
what Ada95 already makes good use of. Claiming that the current Ada model
is without need for improvement, is IMO, a bit biased.  It suggests
that the current visibility model has already achieved perfection.

But, if it never came to pass, I will still sleep just as well. I only
made it a point of discussion. B-)
-- 
Warren W. Gay VE3WWG
http://home.cogeco.ca/~ve3wwg