CVS difference for ai05s/ai05-0125-1.txt

Differences between 1.6 and version 1.7
Log of other versions for file ai05s/ai05-0125-1.txt

--- ai05s/ai05-0125-1.txt	2010/10/26 05:39:46	1.6
+++ ai05s/ai05-0125-1.txt	2010/11/12 05:19:09	1.7
@@ -1,7 +1,6 @@
-!standard  7.3.1(6)                                        08-10-20    AI05-0125-1/01
-!standard  8.3(23)
+!standard  7.3.1(6)                                10-10-30    AI05-0125-1/02
+!standard  8.3(12.3/2)
 !standard  8.3.1(5/2)
-!standard  8.3.1(6/2)
 !class Amendment 08-10-20
 !status work item 08-10-20
 !status received 08-10-03
@@ -63,102 +62,85 @@
 information, this flaw forces O-O type trees to be placed in deep child package
 nesting.
 
+This problem had quite an effect on the design of the graphic subsystem Claw;
+the designers would have used a flatter package structure than was ultimately
+used. Some of the private routines in Claw define raw message handlers,
+which should not be exposed to the user of Claw and surely should not
+be overridden by them.
+
 !proposal
 
-Add wording to ensure that an operation will override even if it is not
-declared.
+Add wording to ensure that an explicit declaration will override
+an inherited operation that is "known" to exist at the point of the
+explicit declaration. Require an overriding_indicator of OVERRIDING
+to ensure the overriding is intentional.
 
 !wording
 
-Add after 8.3(23):
+Modify 8.3(10.d):
 
-A declaration that is a primitive operation of a type extension or private
-extension can also override an inherited subprogram that is not declared, if
-the inherited subprogram has the same defining name and has a type-conformant
-profile, the original corresponding operation of the inherited subprogram is
-an operation of a visible ancestor of the type extension or private extension
-declaration, and the original corresponding operation is visible at the point
-of the declaration.
+  As explained in 7.3.1, "Private Operations", some inherited primitive
+  subprograms are never declared. Such subprograms cannot{, in general,}
+  be overridden, although they can be reached by dispatching calls in
+  the case of a tagged type.
+
+Add after 8.3(12.3/2)
+
+  When a type extension inherits a subprogram that is never declared
+  (see 7.3.1), an explicit declaration of a dispatching operation with
+  the same defining name and a type-conformant profile will nevertheless
+  override the inherited subprogram (for the purposes of dispatching
+  calls), so long as a corresponding dispatching operation of some
+  ancestor type is visible at the point of the explicit declaration.
+  Such an overriding requires an overriding_indicator, which shall be
+  OVERRIDING (see 8.3.1).
 
-[Note: I have avoided using the term "homograph" since a homograph is a 
-declaration and I don't want to change the definition to possibly refer to
-something that is not declared.]
-
-This depends on defining two terms, "original corresponding operation"
-and "visible ancestor".  I would define them as follows:
+Modify 8.3.1(5/2) as follows:
 
-* * * * * * 
-   
-The "original corresponding operation" for a subprogram declaration S is
-defined as follows: If S is an inherited subprogram S2, or overrides an
-inherited subprogram S2, the original corresponding operation of S is the
-original corresponding operation of S2.
-Otherwise, the original corresponding operation of S is S itself.
-
-[The idea is that this is the declaration that caused the slot in the
-dispatch table to be allocated.]
-
-* * * * * * 
-   
-The "visible ancestors" of a type extension or private extension declaration D
-are: 
-
-The parent and progenitor types of the declaration are visible ancestors of D;
-
-If T is a visible ancestor of a declaration, and T is a type extension,
-private extension, or interface type, then:
-
---  and the full view of T is not visible at
-   the point of D, then the parent and progenitor types of the private
-   extension declaration of T are visible ancestors of D;
-
--- d progenitor types of the type extension or
-   interface type are visible ancestors of D.
-
-* * * * * * 
-   
-[These definitions may seem clumsy to some, because my personal preference
-is for mathematically precise definitions.  I tried to define "original
-corresponding operation" in a way that would avoid the possible problem of
-a non-overriding homograph, such as P3 in the second example above.]
-
-Basically, what this all means is that a declaration can override an inherited
-operation P if the program can tell, looking at just the information visible
-to it at that point, that an operation P must exist, even if (due to an
-intermediate type declaration) the operation isn't actually declared.
-
-Other changes that would need to be made:
-
-In the last sentence of 7.3.1(6/1), the phrase "and cannot be overridden"
-would have to be deleted or changed.
-
-8.3.1(5/2-6/2) would need to be changed:
-
     * if the overriding_indicator is OVERRIDING, then the operation
-      shall override a homograph at the place of the declaration or
-      body, or it shall override an undeclared inherited subprogram
-      with the same defining name and type-conformant profile,
+      shall override a homograph {or an undeclared inherited subprogram}
+      at the place of the declaration;
 
-    * if the overriding_indicator is NOT OVERRIDING, then the
-      operation shall not override any homograph or inherited
-      subprogram (at any place).
+[Editor's note: 7.3.1(6/1) also requires changes, but AI05-0029-1 already
+made the needed changes.]
 
-AARM 8.3(10.d) would need to be changed.
 
-   
 !discussion
 
-[Editor's note: This problem had quite an effect on the design of Claw;
-we would have used a flatter package structure than we ultimately ended
-up with. Some of private routines in Claw define raw message handlers,
-which should not be exposed to the user of Claw and surely should not
-be overridden by them.]
+In the case where a parent type of some derived type is "known" to have
+a dispatching operation through inheritance, but because of the
+visibility rules the operation is not declared for the derived type, we
+nevertheless want overriding to occur, for the purposes of dispatching.
+This only happens if the explicit declaration happens at a place
+where the corresponding operation of some ancestor type is visible.
+This is unlike the normal rule, where overriding happens even if the
+inherited operation is declared after the explicitly declared operation.
+To ensure that the overriding is intentional, we require that
+an overriding indicator of OVERRIDING be given in this special circumstance.
+
+We considered allowing the user to specify NOT OVERRIDING at the point
+of the explicit declaration, but it was felt to be an abuse of the
+overriding indicator to have its presence or absence affect the semantics
+of the declaration. So instead we require a "confirming" OVERRIDING indication,
+and make it illegal to write NOT OVERRIDING in this case.
+
+To minimize the incompatibility, if the explicit declaration happens
+at a place where the corresponding operation of the ancestor is not
+visible, no overriding occurs, and if an overriding indicator were given,
+it would have to indicate NOT OVERRIDING.
+
+!ASIS
+
+The overriding relationship is not currently represented in
+ASIS. If it were, it would have to properly reflect this new
+kind of overriding.
 
 !example
+
 
-    
 !ACATS test
 
+ACATS B and C tests are needed for this feature.
 
 !appendix
 
@@ -245,7 +227,7 @@
 what inherited subprograms get overridden, whether those subprograms are
 declared or not.  Furthermore, I would definitely want the "overriding"
 keyword to be legal on such overriding subprograms, and "not overriding"
-to be illegal.] 
+to be illegal.]
 
 Add after 8.3(23):
 
@@ -257,15 +239,15 @@
 declaration, and the original corresponding operation is visible at the point
 of the declaration.
 
-[Note: I have avoided using the term "homograph" since a homograph is a 
+[Note: I have avoided using the term "homograph" since a homograph is a
 declaration and I don't want to change the definition to possibly refer to
 something that is not declared.]
 
 This depends on defining two terms, "original corresponding operation"
 and "visible ancestor".  I would define them as follows:
 
-* * * * * * 
-   
+* * * * * *
+
 The "original corresponding operation" for a subprogram declaration S is
 defined as follows: If S is an inherited subprogram S2, or overrides an
 inherited subprogram S2, the original corresponding operation of S is the
@@ -274,11 +256,11 @@
 
 [The idea is that this is the declaration that caused the slot in the
 dispatch table to be allocated.]
+
+* * * * * *
 
-* * * * * * 
-   
 The "visible ancestors" of a type extension or private extension declaration D
-are: 
+are:
 
 The parent and progenitor types of the declaration are visible ancestors of D;
 
@@ -291,9 +273,9 @@
 
 -- otherwise, the parent and progenitor types of the type extension or
    interface type are visible ancestors of D.
+
+* * * * * *
 
-* * * * * * 
-   
 [These definitions may seem clumsy to some, because my personal preference
 is for mathematically precise definitions.  I tried to define "original
 corresponding operation" in a way that would avoid the possible problem of
@@ -386,5 +368,25 @@
 Sent: Monday, August 23, 2010  6:52 AM
 
 The specification of A1.A3 misses a "with A1.A2;"
+
+****************************************************************
+
+From: Tucker Taft
+Sent: Friday, October 29, 2010  11:40 PM
+
+[Version /02 of the AI was attached - Editor.]
+
+Here is an AI attempting to address another thorny "Adam" question.  Basically,
+we say that an explicit declaration of a dispatching operation on a type
+extension overrides an inherited subprogram that is never declared, if the
+explicit declaration occurs at a point where a corresponding dispatching
+operation of some ancestor is visible.
+
+In other words, if you "know" that you inherited a dispatching operation, you
+can override it for the purposes of dispatching calls, even if the inherited
+subprogram isn't "officially" declared.
+
+We require an overriding_indicator of OVERRIDING in this special case, so there
+is no ambiguity, and to prevent a "silent" inconsistency with Ada 95/2005.
 
 ****************************************************************

Questions? Ask the ACAA Technical Agent