CVS difference for ais/ai-00262.txt

Differences between 1.6 and version 1.7
Log of other versions for file ais/ai-00262.txt

--- ais/ai-00262.txt	2001/05/11 03:46:21	1.6
+++ ais/ai-00262.txt	2001/06/02 04:13:15	1.7
@@ -2533,3 +2533,87 @@
 analyze compilation units.
+!topic Extending the private part of a package
+!reference RM95-10.1.2(8)
+!from Michael Gray
+!sent Thursday, May 17, 2001  7:22 AM
+This issue was raised in reference to child packages. The spec of a child
+package can be regarded as an extension to the spec of its parent (Rationale
+II.7, "We can think of the child package as being declared inside the
+declarative region of its parent but after the end of the specification of
+its parent; most of the visibility rules stem from this model.") However, a
+private child cannot be used as an extension of the private part of its
+parent. This is because a private child is not visible to the same set of
+places that its parent's private part is visible to; specifically, it is not
+visible to the private parts of its siblings, whereas its parent's private
+part is. There seems to have been some ambiguity about this in the
+development of Ada95; Rationale section II.8 says "The other extra rule is
+that the visible part of the private child can access the private part of
+its parent. This is quite safe because it cannot export information about a
+private type to a client because it is not itself visible. Nor can it export
+information indirectly via its public siblings because, as mentioned above,
+it is not visible to the visible parts of their specifications but only to
+their private parts and bodies." I.e. this is saying that a private package
+is visible to the private part of its public siblings, which is in flat
+contradiction to LRM 10.1.2 (8), "If a with_clause of a given
+compilation_unit mentions a private child of some library unit, then the
+given compilation_unit shall be either the declaration of a private
+descendant of that library unit or the body or subunit of a (public or
+private) descendant of that library unit." This rule prevents a public
+package "with"ing its private sibling, which therefore prevents the private
+part of the public package getting visibility of its private sibling. We
+cannot see a reason for this restriction.
+The situation arose in the following context. We had a 'framework' of
+packages A and A.B. We wished to provide a number of 'concrete' extensions
+A.X and A.B.X; A.Y and A.B.Y; etc, where A.X etc are private (they are
+intended for use only by A.B.X). But this was impossible because although
+A.B's private part has visibility of A's private part, A.B.X's private part
+does not have visibility of A.X's private part, because A.B (and therefore
+A.B.X) cannot 'with' its private sibling A.X.
+From: Randy Brukardt
+Sent: Friday, May 25, 2001  9:53 PM
+The reason for the restriction is to prevent re-export of information from a
+private package, and to prevent units outside of the "subsystem" from
+depending on the private package. See AARM 10.1.2(8.a-l) for some commentary
+on this.
+On the other hand, there is a proposal on the table (AI-262) for "private
+with"s, which would allow withing packages only to be used in the private
+part of a package. This also would allow the withing of private packages in
+the specs of sibling packages. This is discussed in AI-262, which isn't
+written up yet. Does this seem like it would solve your problem??
+From: Michael Gray
+Sent: Tuesday, May 29, 2001  6:02 AM
+> The reason for the restriction is to prevent re-export of information from a
+> private package, and to prevent units outside of the "subsystem" from
+> depending on the private package. ...
+Sure, I understand that. What I meant was, we couldn't see a reason why the
+language should not make the content of a private package visible to the
+/private/ part of its sibling.
+> ... Does this seem like it would solve your problem??
+Yes it does.
+I had been thinking along the following lines: if A.B is a public child and
+A.C a private child, then A.B should be able to "with" A.C, such that this
+would give /only/ the private part of A.B visibility of A.C. But having
+skimmed the 26 pages of AI-262, I agree that it would be better to have some
+"private with" syntax by which context clauses that are needed only by the
+private part of a package can be differentiated from context clauses that
+are needed by the visible part (or both parts).

Questions? Ask the ACAA Technical Agent