Re: Need advice re package organization.

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

"Warren W. Gay VE3WWG" <ve3wwg@cogeco.ca> wrote in message
news:7GfWa.5186$mv6.907516@news20.bellglobal.com...
> Randy Brukardt wrote:
> > 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.

Certainly possible.

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

OK. Let me understand you. This translates to "I want to see private
things".

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

This translates to "I do not want to see private things." Does it make it
clear why I'm confused? :-)

You said that you need visibility on the parent's private types, but you
clearly don't need to be a child to have that. And if you do need visibility
on items in the private part, then you need that. Finally, if there is stuff
that you don't want anyone to have visibility on, you put item into the
body. So where's the problem?

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

Sorry, I don't know C++ well enough to understand the detailed meaning of
these terms. I'd like to see an actual Ada proposal, which I can try to
understand.

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

I don't believe that it is possible to graft fine-grained visibility control
into Ada. It's been tried before (during the Ada 9x process) and it didn't
work out then.

It would make perfect sense for an Ada-like language to have this sort of
control, but not Ada itself (because of compatibility issues).

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

I still have no clear idea what you have in mind. I'm leary of saying that
we need fine-grained visibility control, but only of "record views"
(whatever that is). Why does your problem not apply to other declarations
(subprograms and subtypes) as well?

> > 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, I don't think you're being entirely fair about this discussion.
>
> We're talking about protected access of classes (C++).

As I said above, I don't know C++ well enough to know exactly what it is
that you are proposing. And in any case, Ada is not C++. Please describe
what you want in Ada terms, with Ada syntax.

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

No, the visibility model is far from perfect. The problem is that it has
resisted most attempts to change it, because it is very hard to come up with
a compatible change that works in ALL cases. A lot of ideas make perfect
sense in the normal case, but come to grief on bizarre corner cases that no
one really cares about (but have to work).

Having a lot of experience with that, I tend to resist making another
attempt, particularly without a clear justification. That IS my bias.

> But, if it never came to pass, I will still sleep just as well. I only
> made it a point of discussion. B-)

Well, it does not hurt to bring up ideas. I just would like to understand
what they are well enough to understand why the language doesn't provide it
already.

                    Randy.