CVS difference for ais/ai-20217.txt

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

--- ais/ai-20217.txt	2002/01/05 01:07:43	1.5
+++ ais/ai-20217.txt	2002/02/05 02:06:24	1.6
@@ -1823,3 +1823,107 @@
 
 *************************************************************
 
+From: Tucker Taft
+Sent: Monday, February 4, 2002,  5:49 PM
+
+[ai-217-02 is the AI formerly known as "ai-277" ;-]
+
+I thought I would mention that we went ahead and did a prototype
+implementation of incomplete type stubs, following the suggestion
+from Erhard where the package that defines the type is specified
+at the point of the stub.  It turned out to be a relatively modest
+enhancement to the existing support for incomplete types.
+
+The only tricky part is defining under exactly what circumstances a
+reference to the stub (say "P.T") is equivalent to a reference to
+the completing type (say "A.B.C.T").  The basic rule was that,
+presuming the package name given in the type stub declaration
+was "A.B.C" then "A" must be the name of a (root) library
+package that is visible in package Standard at the point
+of the reference (because it was "with"ed or because it encloses
+the point of reference); similarly B must be a (child) library package
+visible within A, and C must be visible within B.  A, B, and C must
+not be renamings, to avoid multiple names for the same completion.
+And of course a (non-type-stub?) type with the same name as the type stub
+(say "T") must be declared within the visible part of "C".  Presumably if "A"
+is not *directly* visible (because it is hidden by an inner
+homograph) that is OK, so long as <pkg_standard>.A is visible.
+
+This check is done at pretty much any use of P.T *except* as a
+designated subtype, as well as any dereference of an access-to-P.T.
+One question is if A.B.C is visible at the point of a declaration
+of an access-to-P.T type, should you "remember" that?  Our presumption
+was no, since the user could have written "A.B.C.T" if they had wanted
+those semantics.  Instead, if they write P.T as the designated subtype,
+then this may be dereferenced only where A.B.C is visible.
+
+Note that we require A.B.C to be visible, not merely in scope, so
+that "ripple" effects due to adding or removing a "distant" with
+clause don't alter the semantics.
+
+I suppose another question is what happens when there are two
+incomplete stubs with the same completing type.  Are they considered
+statically matching subtypes?  Or only where their (shared) completion
+is "available."  (I am using the term "available" to mean
+the full type's full name, e.g. A.B.C.T, is visible.)
+
+*************************************************************
+
+From: Randy Brukardt
+Sent: Monday, February 4, 2002,  5:49 PM
+
+> [ai-217-02 is the AI formerly known as "ai-277" ;-]
+
+Well, actually, AI-00217-03 (the third alternative of AI-217) is the AI
+formerly known as AI-277.
+
+> I thought I would mention that we went ahead and did a prototype
+> implementation of incomplete type stubs, following the suggestion
+> from Erhard where the package that defines the type is specified
+> at the point of the stub.  It turned out to be a relatively modest
+> enhancement to the existing support for incomplete types.
+
+Great! I need this yesterday in the Claw Builder. :-)
+
+I've been waiting for a proposal (and the upcoming meeting) before doing
+anything about an implementation.
+
+How did you describe the package "name" in the incomplete stub (since it cannot
+be a 'name' in the Ada sense, as it is not visible and cannot 'denote' anything
+in the stub -- at least if it is to be a useful construct)?
+
+> The only tricky part is defining under exactly what circumstances a
+> reference to the stub (say "P.T") is equivalent to a reference to
+> the completing type (say "A.B.C.T").  The basic rule was that,
+> presuming the package name given in the type stub declaration
+> was "A.B.C" then "A" must be the name of a (root) library
+> package that is visible in package Standard at the point
+> of the reference (because it was "with"ed or because it encloses
+> the point of reference); similarly B must be a (child) library package
+> visible within A, and C must be visible within B.  A, B, and C must
+> not be renamings, to avoid multiple names for the same completion.
+> And of course a (non-type-stub?) type with the same name as the type stub
+> (say "T") must be declared within the visible part of "C".  Presumably if "A"
+> is not *directly* visible (because it is hidden by an inner
+> homograph) that is OK, so long as <pkg_standard>.A is visible.
+
+Is the restriction against renames really necessary? It seems odd to introduce
+a case where a renamed package is not semantically equivalent to the package it
+renames. Such a restriction may make sense for the declaration (that would be
+equivalent to the rule for child packages), but I don't think you would want to
+enforce that on the checks (which is the 'use' of the rename, which is
+certainly allowed for child units).
+
+> ...
+>
+> I suppose another question is what happens when there are two
+> incomplete stubs with the same completing type.  Are they considered
+> statically matching subtypes?  Or only where their (shared) completion
+> is "available."  (I am using the term "available" to mean
+> the full type's full name, e.g. A.B.C.T, is visible.)
+
+I would think only when the (shared) completion is available. But it doesn't
+seem important either way.
+
+*************************************************************
+

Questions? Ask the ACAA Technical Agent