From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00 autolearn=ham autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 103376,c35d69ccf1ab6b78 X-Google-Attributes: gid103376,public From: cosc19z5@Bayou.UH.EDU (Spasmo) Subject: Re: Another OOP Question Date: 1996/08/20 Message-ID: <4vblni$j29@Masala.CC.UH.EDU> X-Deja-AN: 175251729 organization: University of Houston newsgroups: comp.lang.ada Date: 1996-08-20T00:00:00+00:00 List-Id: Jon S Anthony (jsa@alexandria) wrote: : In article <4v609i$fgj@Masala.CC.UH.EDU> cosc19z5@Bayou.UH.EDU (Spasmo) writes: : > Ok, here's another OOP question about accessing private members. : > Right now let's say I have a class called A, and B inherits from : > A. Now let's say that B needs to access a private data member : > in A -- is there any way I can do this without placing B into : > a Child package? : I'm not sure I follow this. Do you mean "private" in the C++ sense or in : the Ada sense? In the Ada sense, if A and B are in the same package, then : you get this for free: Well private in the Ada sense. As usual I'm being way too vague (I need to get out of this habit!). I've got a class defined in one package, and an inherited class in another package so I'm speaking of 2 classes in 2 different packages. That's pretty much how I'm trying to commit myself in terms of doing things. Ada provides such awesome modular programming support that there's no reason not to use it. [Example snipped, it was about another scenario] : 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). : > The reason I'd like to now is because I'm confronted with such a : > scenario and Child packages (among other things) will make all of my : > parents members visible which is the last thing I want to do. : 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. : package P is : type A is tagged private; : ... : private : type A is... : end P; : package P.C is : -- : -- None of P's private definitions are visible here. : type B is new A with private; : ... : private : -- : -- P's private section is visible here and in the body of P.C : type B is ... : end P.C; : with P.C; : procedure Proc is : -- : -- Nothing of P's private section is visible here... : ... : end Proc; 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. : My guess is that you are not clear on child package visibility rules : and that you really do want to use a child package and that it will : work just fine for what you want to achieve. 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!). : Lastly, if you mean "private" in the C++ sense, you have to put the actual : definitions in the _bodies_ of the packages. The only way for anything : else to get at these will be through accessors (public or private) defined : in the specification. Nothing outside the body (and any separates) has : direct access. Ok, I'll try to be precise in what I am trying to do and use an example from *gasp* C++. I should have done this from the start but to be honest I didn't want to drag C++ in there since the more I use Ada the more I look down on C++, but it seems that for example's sake this may be the way to go. Ok, consider this scenario. A person is working on a an OO package. This package defines a class and all the operations to be performed on this class. No problemo so far, but there's something the 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, 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? 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. The precise scenario that I'm confronted with is this. I'm working on some menu classes to get more familiarized with OOP in Ada. Anyway I've written some wrappers for enhanced I/O by accessing C classes and I've made it so that the output is double buffered. Naturally to share the screen items need to be able to access the current buffer. 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. Now there is one idea and that's just having a function that returns an access to this buffer so that we can get the screen that we're working on. Of course the problem is that in order to circumvent this whole mess such a function would have to be made public which would give other non-related units access to this private data member (via an alias). 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? Wow what a mouthfull! :) : /Jon : -- : Jon Anthony : Organon Motives, Inc. : 1 Williston Road, Suite 4 : Belmont, MA 02178 : 617.484.3383 : jsa@organon.com -- 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