Re: Another OOP Question

[cosc19z5@Bayou.UH.EDU (Spasmo)]

Jon S Anthony (jsa@alexandria) wrote:
: 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.

Ok cool (I just have the tendency to make assumptions so at times
I can be really vague).  


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

Oh ok.  I'm relatively sure that the body of the child (public
stuff) was able to access the private goodies of the parent.
I will however do this again to make 100% sure and report it as
a bug if this is the case.  Thanks.



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

Right.  I like data abstraction and hiding what doesn't need
to be shared so I get a little edgy if I enter a scenario
where I have to expose more of my implementation than I have
to.


: 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++)

Ok this is a new one.  I was under the impression that package
bodies were the equivalent of public.  I mean if you put stuff
in package bodies then that stuff becomes available to 
any module that withs that package, or have I missed something
again?



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

Ok, then it is a possible bug. Again I'll make 100% sure.  Don't
want to waste the time of the GNAT folks by reporting bogus
bugs :).


: > 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"?

Well my concerns revolve around revealing more of my implementation
than I absolutely have to.  I mean if I want to share a data item
then I'll do so only if I determine that there is no other 
practical way of doing so, and then I'll try to restrict sharing
as much as possible.  I'm pretty sold on the concept of information
hiding.  As for "available to all", I meant visible to any module
that withs it.  So with returning pointers to the internal type
I'd end up making it "public" if you will so that even non-child
packages can get a hold of it, and that's something that is
worrying me as well.

[Snip]


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

Ok, let me make sure that I'm on the same wavelength so to speak.
What you mean is something like this:

package A is
	type Data_Type is ... -- This is "private"????

	...

	private  -- Everything from here until the end is protected
end A;

Is this correct?  If so then it seems to contradict what I've been
seeing.  Anything I dump in the non-private part of a package has
always been public.



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

By protected type you mean the protected task right?  Isn't that
a bit of overkill?



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

Right, you mean protected as in the protected task type eh?


: > mess such a function would have to be made public

: Why???

Ok well a bit of snipping occurred so I can't quite recall the
context in which I made the above statement. I believe it was
with regards to returning the pointer in which case it would
be made public so I can avoid the child package entirely (and
hence the data sharing).



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

Interesting but there are a few problems.  The first is that
my box class is supposed to be able to support multiple
screens (virtual screens), which is why I encapsulated the
buffer alias in the type.  That way we could have different
screens with boxes and the like (like intros and so forth).
The way Buffer is now, it's only one screen for every
instance.  We could make a type of Buffer and declare instances
of it but then that brings us back to the problem, which we
still have here -- A is visible to the children.  This is
something we can't get around is it?  It looks like I will
have to deal with this fact.


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

But the other data items of A are visible so that's still a
problem.


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

Well yes if one uses child classes.  Maybe I just need to get a
good book that deals specifically with Ada95's OOP features and
that talks some more about visibility. 

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

: 617.484.3383
: jsa@organon.com


Thanks a million for your help!


--
Spasmo
"Everyone has secrets, but sometimes you get caught,
 So if it's just between us, my silence can be bought"
	"Blackmail" by Sloppy Seconds