Re: Another OOP Question

[jsa@alexandria (Jon S Anthony)]

In article <4vblni$j29@Masala.CC.UH.EDU> cosc19z5@Bayou.UH.EDU (Spasmo) writes:

> Jon S Anthony (jsa@alexandria) wrote:
> : In article <4v609i$fgj@Masala.CC.UH.EDU> cosc19z5@Bayou.UH.EDU (Spasmo) writes:
[....]
> : If you want A and B in separate packages, then in order for the impls of
> : B's ops to have access to the private definition of A, it needs to go into
> : a child package.
> 
> Right, that's pretty much the scenario I'm working with.  I'm
> using class to mean a tagged datatype and its associated
> functions all placed into a package since that's how I'm doing
> things, but of course others may do things differently so
> forgive the error (and arrogance).

Sounds fine to me.  No error or arrogance.


> : I don't understand why you make this claim.  Children do not make any of
> : the private stuff of the parent visible:
> 
> Are you sure about this?  I was able to pick into the private
> goodies of my parent when I declared a child class in Gnat3.05
> for DOS.  It was something like this:
> 
> The package with the parent had a class that was tagged private.
> I declared a child package and was able to use the data fields
> 	of the class in the parent that were private.

Yes, I'm sure.  But the problem is we are talking about different
things and so it is no wonder we are not communicating.  What you are
really concerned about here is that the _private_ section of a child
has access to the _private_ section of the parent (and the visible
part too, of course).  If GNAT is allowing the _visible_ part of the
child access to the private part of the parent (and that child is NOT
a private child), then GNAT is broken.  Report the bug.

A child is really an extension of the declarative region of the
parent.  Some people (as you indicate for yourself) have voiced
concerns about this.  For myself, I see it as simply a case of
recognizing what is happening and being appropriately careful.

Another point that may be confusing you is that "private" in Ada is
really the analogue of "protected" in C++.  The "private" of C++ is
achieved by use of package _bodies_ (which have no analogue in C++)


> Well yes I know of the above, again I'm being vague.  I meant
> that the child package could see the parent package's private
> goodies, not that the child package would make the parent's
> private goodies available to whatever package with'ed it. 

But _only_ the _private_ section of the child can see these private
goodies of the parent.  So the visible part of the child has no more
access to the private section of the parent than a standard client.


> Well I knew about the above so I believe I'm relatively clear
> on the visibility rules.  What was troubling me was that the
> way I was doing it was making all of my parent's private stuff
> visible to the child, rather than finding a way to just access
> the one member I wanted in question.  Of course I could try
> returning a pointer to the internal aliased type and indirectly
> manipulate it through there, but the thing would be clumsy and
> once again it wouldn't change having to deal with the child
> package (unless I wanted this to be available to all!).

OK, I know you have some concerns about this, but it is not clear
what they are or more to the point why you have them.  I also don't
understand what you mean by this phrase "available to all".  To "all"
what"?


> designer is confronted with.  There's a data item whose direct
> access may be of great use to any children.  At this point in
> time the designer cannot visualize what the children might
> do with it, but he/she realizes that being able to directly
> access this data item can be of importance.  Now the designer
> wants to make this data item visible without making anything
> else visible, but at the same time this person cannot just
> make this data item visible to everything -- only children.
> 
> The scenario is similar to C++'s protected types.  Here
> you have items that cannot be accessed except by inherited
> classes,                                         ^^^^^^^^^ Sub

> and the thing is you can have protected types
> and private types mixed in so that only the stuff you want
> to be protected is in fact protected.  Ok so far so good?

Yes.


> Now with Ada you have the private section of a package.
> This makes everything private but child packages can see
> into this.  The problem is that if you use child packages
> the children can see EVERYTHING.

Yes, just like in C++ any child can see ALL the "protected" stuff.
If you want the _C++_ private bit, too, put the definitions in the
_body_.  Then they are _only_ visible there and no where else!
Another route that is more flexible (but pays for it by letting in
more possible "seers") is to use a _private_ child package.


> that the output is double buffered.  Naturally to share
> the screen items need to be able to access the current
> buffer.

This sounds like a classic shared resource

Suggestion: Capture it with a protected type.


> Now the box class has an access to the buffer
> so it can modify it (via alias), but of course to be able
> to write to the same screen children need to be able
> to get a hold of this buffer since they want to do more
> with it.  Ie: the next child is a textbox so it needs
> to put text in the box and it needs to get the buffer
> to do this.

Definitely use a protected type.  This is off topic from your concern
about C++ style "private"/"protected" stuff, but it will make your
current problem evaporate.  Egads, note too, that "protected type" in
Ada has nothing to do with "protected" in C++.


> mess such a function would have to be made public

Why???

package P is
    type A is tagged private;
    ...
private
    type A is tagged ...
    ...
    protected Buffer is
        function Get...
        entry Put....
    private
        The_Buffer : ... I guess something to do with A...
    end Buffer;
end P;

Only children can see Buffer and ONLY in their private section or
bodies.  Buffer is _NOT_ public.  More over, The_Buffer is not even
visible to the children or even the other things in P!  It is ONLY
visible in the body of Buffer.


> Messed up isn't it?  Maybe my whole concept of how
> I'm doing this is flawed, but still am I right in
> assuming that there is nothing equivalent to
> C++'s protected type?  

Absolutely not.  The equivalent is Ada private section definitions.


/Jon
-- 
Jon Anthony
Organon Motives, Inc.
1 Williston Road, Suite 4
Belmont, MA 02178

617.484.3383
jsa@organon.com