CVS difference for ai05s/ai05-0074-1.txt
--- ai05s/ai05-0074-1.txt 2007/10/25 05:43:52 1.1
+++ ai05s/ai05-0074-1.txt 2007/10/26 01:37:57 1.2
@@ -923,7 +923,7 @@
****************************************************************
From: Randy Brukardt
-Date: Wednesday, October 24, 2007 11:326 PM
+Date: Wednesday, October 24, 2007 11:32 PM
...
> At any rate, it would be good to explain what exactly is visible after "end
@@ -972,6 +972,273 @@
I'm sure there are more issues to consider. I haven't seen any posting by Steve Baird
on this yet. ;-) The whole thing sounds like fun. :-(
+
+****************************************************************
+
+From: Tucker Taft
+Date: Thursday, October 25, 2007 7:25 AM
+
+Randy Brukardt wrote:
+> Pascal notes:
+>
+> ...
+>> At any rate, it would be good to explain what exactly is visible after
+> "end
+>> private" and how you ensure that no private information is leaked out of
+> the
+>> package.
+>
+> Let's just look at a few cases that would need to be defined:
+>
+> * What if is there is a use clause in the private part? Does it extend into
+> the following non-private part(s)? [This was from Jean-Pierre.] I think the
+> answer has to be no, ...
+
+Agreed, clearly no.
+
+>
+> * How about "additional operations" of a type? That is, in something like:
+>
+> package P is
+> type Q is limited private;
+> private
+> type Q is record
+> A : Integer := 10;
+> end record;
+> end private;
+> Obj : Q;
+> B : Boolean := (Obj = Obj);
+> end P;
+>
+> Again, probably not. More generally, declarations in a private part
+> should not be visible in a following visible part, so we'd have visibility
+> going out at "end private;" and then returning when we reached the body.
+
+Agreed.
+
+>
+> with Func;
+> package P is
+> type Q is limited private;
+> private
+> type Q is access Integer;
+> Obj : Q;
+> end private;
+> I : Integer := Obj.all;
+> end P;
+>
+> This reduced visibility worries me, as we generally don't lose visibility
+> in a single package: everything is additive (visible part, private part,
+> body). It seems to offer the opportunity for more anomalies.
+
+Perhaps, though I think nested packages with private
+parts are pretty similar. With nested packages,
+visibility comes and goes.
+
+Child packages are perhaps even closer to this. When
+you start a child package, although they logically "follow"
+the private part of their ancestor packages,
+they don't "see" the private part. When you hit
+the private part of the child package, suddenly
+the private declarations of all the ancestors become
+visible.
+
+So from an implementation and anomaly point of view,
+at the "end private;" you might imagine you are starting a
+child package, which cannot take advantage of visibility
+on the parent's private part until it hits its own private
+part or body.
+
+> * Do public children see all of the visible declarations but none of the
+> private ones of their parent? (Seems necessary.)
+
+They don't see the private declarations until they hit their
+own private part or body. No real surprise here.
+
+>
+> I'm sure there are more issues to consider. I haven't seen any posting by
+> Steve Baird on this yet. ;-)The whole thing sounds like fun. :-(
+
+Clearly there will be some implementation effects, but I
+don't see many semantic anomalies on the visibility side,
+since I believe a child package experiences much the same
+"coming and going" of visibility.
+
+The anomalies I could imagine would have to do with "completion"
+and overriding, since these kinds of things can't be
+simulated by a child package (though a child subprogram
+can "simulate" overriding in certain non-tagged cases).
+And I agree we will need to work them through if we decide
+to pursue this proposal. I am happy to do so, after
+I have finished my other homework ... ;-).
+
+****************************************************************
+
+From: Robert A. Duff
+Date: Thursday, October 25, 2007 9:15 AM
+
+> Let's just look at a few cases that would need to be defined:
+>...
+
+I'm surprised by Tucker's answer. My answer is that "obviously", the
+visibility in the second visible part includes everything that came before,
+just as if "end private;" were erased. (Now Tuck can tell me why that's
+stupid. ;-))
+
+The purpose of privacy is to hide things from OTHER packages, not from the
+package itself. This should be legal:
+
+ package P is
+ private
+ type Base_Type is range 1..2**31-1;
+ end private
+ subtype Exported_Type is Base_Type'Base;
+ end P;
+
+to get a type that has at least 32 bits, but matches the hardware bounds. I
+don't want to pester the client with a useless name -- Base_Type is visible in
+the visible part, but not in clients.
+
+By the way, C++ has a similar feature. It might help to look at the details,
+which I don't remember. Of course C++ visibility is quite different from Ada,
+so it might be irrelevant. And C++ visibility is broken in some ways, so we
+don't necessarily want to mimic it -- but it couldn't hurt to look.
+
+> * Do public children see all of the visible declarations but none of the
+> private ones of their parent? (Seems necessary.)
+
+Yes.
+
+> I'm sure there are more issues to consider. I haven't seen any posting by
+> Steve Baird on this yet. ;-)The whole thing sounds like fun. :-(
+
+Indeed. I'm not at all sure the whole idea will work.
+
+****************************************************************
+
+From: Jean-Pierre Rosen
+Date: Thursday, October 25, 2007 7:34 AM
+
+> Let's just look at a few cases that would need to be defined:
+>
+And:
+
+I assumed when I read the proposal that there could be several private
+parts, but I didn't see any mention about that. Is it the intent? That
+would certainly seem logical from a user point of view:
+
+package Pack is
+ -- visible
+private
+ -- hidden
+end private;
+
+ -- visible again
+
+private
+ -- hidden again
+end Pack;
+
+Have great fun with visibility going in and out!
+
+****************************************************************
+
+From: Randy Brukardt
+Date: Thursday, October 25, 2007 7:56 PM
+
+...
+> > with Func;
+> > package P is
+> > type Q is limited private;
+> > private
+> > type Q is access Integer;
+> > Obj : Q;
+> > end private;
+> > I : Integer := Obj.all;
+> > end P;
+> >
+> > This reduced visibility worries me, as we generally don't
+> lose visibility
+> > in a single package: everything is additive (visible part, private part,
+> > body). It seems to offer the opportunity for more anomalies.
+>
+> Perhaps, though I think nested packages with private
+> parts are pretty similar. With nested packages,
+> visibility comes and goes.
+>
+> Child packages are perhaps even closer to this. When
+> you start a child package, although they logically "follow"
+> the private part of their ancestor packages,
+> they don't "see" the private part. When you hit
+> the private part of the child package, suddenly
+> the private declarations of all the ancestors become
+> visible.
+
+Not really: within a single unit, all that can happen is the *addition* of
+new things. Once you can see the additional operations, they stay visible
+until the end of the unit. (The situation in outer units may be different,
+but I don't see that as relevant -- we know that visibility can change in
+external units, but it doesn't reduce *directly within* a unit.)
+
+> So from an implementation and anomaly point of view,
+> at the "end private;" you might imagine you are starting a
+> child package, which cannot take advantage of visibility
+> on the parent's private part until it hits its own private
+> part or body.
+
+A child package starts with a "clean" visibility slate, into which the
+parent and other "withs" are loaded. Handling the private part at that point
+is (relatively) easy. A "end private" has a complex visibility state,
+already existing, where things would have to be subtracted piece-meal.
+(Reloading is not an option: you haven't stored it out yet!) This seems
+sustantially more complex. (Of course, I haven't tried implementing this, so
+it might prove easier than I think now.)
+
+> > * Do public children see all of the visible declarations but none of the
+> > private ones of their parent? (Seems necessary.)
+>
+> They don't see the private declarations until they hit their
+> own private part or body. No real surprise here.
+>
+> > I'm sure there are more issues to consider. I haven't seen any posting
+by
+> > Steve Baird on this yet. ;-)The whole thing sounds like fun. :-(
+>
+> Clearly there will be some implementation effects, but I
+> don't see many semantic anomalies on the visibility side,
+> since I believe a child package experiences much the same
+> "coming and going" of visibility.
+
+No, only "coming". There's no "going": once the private part of a parent is
+visible, it stays that way. It's the "going", for declarations in the same
+unit, which I think doesn't exist currently and has the potential to add
+complications.
+
+Now, I realize that other models of child compilations are possible, but for
+us, each one starts with a clean slate which is built up with whatever is
+needed (a parent is just a hidden "with" of a unit). The only magic is
+making the private part visible when the child "private" is reached, and
+that is a pure addition to visibility.
+
+> The anomalies I could imagine would have to do with "completion"
+> and overriding, since these kinds of things can't be
+> simulated by a child package (though a child subprogram
+> can "simulate" overriding in certain non-tagged cases).
+> And I agree we will need to work them through if we decide
+> to pursue this proposal. I am happy to do so, after
+> I have finished my other homework ... ;-).
+
+Sounds good, especially the part about finishing your other homework. :-)
+
+This issue and the possible solutions are on the agenda for Washington,
+although I'd expect any brainstorming on it to come after we get our other
+work done. (You'll note it is right on the bottom of the list... ;-)
+
+BTW, you are welcome to give the same treatment to the write-up of my
+proposal for this problem that you'll find in AI05-0074-1 (another AI number
+that I fear will live in infamy, like AI-217 [limited with] and AI-359 [the
+4(!) previous versions of this problem]). I hope I can take it as well as I
+dish it out. ;-)
****************************************************************
Questions? Ask the ACAA Technical Agent