CVS difference for ais/ai-00228.txt

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

--- ais/ai-00228.txt	2003/03/04 04:56:22	1.7
+++ ais/ai-00228.txt	2003/05/24 00:51:35	1.8
@@ -1,4 +1,4 @@
-!standard  3.09.3    (6)                             03-02-20  AI95-00228/04
+!standard  3.09.3    (6)                             03-05-03  AI95-00228/05
 !standard  8.05.4    (5/1)
 !class binding interpretation 03-01-07
 !status Amendment 200Y 03-02-20
@@ -8,13 +8,13 @@
 !priority Low
 !difficulty Medium
 !qualifier Clarification
-!subject Premature use of 'shall be overridden' subprograms
+!subject Premature use of "shall be overridden" subprograms
 
 !summary
 
-A subprogram which 'shall be overridden' in the sense of 3.9.3(6) is not
+A subprogram which "shall be overridden" in the sense of 3.9.3(6) is not
 subject to the restrictions that apply to an abstract subprogram. It is
-illegal to rename a 'shall be overridden' subprogram.
+illegal to rename a "shall be overridden" subprogram.
 
 !question
 
@@ -45,23 +45,23 @@
 
 !recommendation
 
-(See Summary.)
+(See summary.)
 
 !wording
 
-(See Corrigendum.)
+(See corrigendum.)
 
 !discussion
 
-The essence of the question revolves around the difference between 'abstract'
-and 'shall be overridden'. AI95-00211 seems to have been written with the
+The essence of the question revolves around the difference between "abstract"
+and "shall be overridden". AI95-00211 seems to have been written with the
 assumption that these terms were more or less synonymous, but in fact they are
 not. By definition, an abstract subprogram has no implementation, so we must
-prevent any construct that could lead to non-dispatching calls to such a
+prevent any construct that could lead to nondispatching calls to such a
 subprogram. On the other hand, the rules of 3.9.3(6) ensure that an
-overrider will be provided for each 'shall be overridden' subprogram, and that
+overrider will be provided for each "shall be overridden" subprogram, and that
 this overrider will not be abstract (assuming the type itself is not abstract).
-So non-dispatching calls to such subprograms are fine, because we can guarantee
+So nondispatching calls to such subprograms are fine, because we can guarantee
 that there exists a proper implementation.
 
 To illustrate the difference, consider the following example, which is somewhat
@@ -97,20 +97,20 @@
     end P4;
 
 In package P2, T2 inherits a function F which shall be overridden. In this
-instance the overrides appear in the private part, but at the point of the
-type declaration we know that an override is coming. So in the visible part
-of P2 it is legal to evaluate the attribute Access for F in a default
-expression (note that most other usages of F are illegal because they would
-freeze T2 before its full definition). This wouldn't be true for abstract
-subprograms.
+instance the overriding subprogram appears in the private part, but at the
+point of the type declaration we know that an overriding subprogram is coming.
+So in the visible part of P2 it is legal to evaluate the attribute Access for
+F in a default expression (note that most other usages of F are illegal because
+they would freeze T2 before its full definition). This wouldn't be true for
+abstract subprograms.
 
 In package P3, when we derive from P2.T2, P2.F being a function with a
 controlling result, it has to be overridden. Again, F'Access is legal in a
 default expression in the specification of P3, even before the declaration
-of the overrider.
+of the overriding function.
 
 In package P4, T4 is declared to be an abstract type, so the inherited F is
-abstract. It may or may not be overriden, but it is illegal, say, to
+abstract. It may or may not be overridden, but it is illegal, say, to
 evaluate F'Access before a non-abstract override has been given.
 
 A similar example can be constructed with an abstract root type and an
@@ -141,16 +141,17 @@
     package P4 is
         type T4 is new abstract P1.T1 with ...;
         -- Inherits a P which is abstract.
+        -- P'Access is illegal.
     end P4;
 
 The inheritance mechanisms are similar in this second example, except that
-the procedure P inherited by P3.T3 does not have the 'shall be overridden'
+the procedure P inherited by P3.T3 does not have the "shall be overridden"
 property. That's because the parent type, P2.T2, is guaranteed to have a
-non-abstract primitive procedure P (even though the overrider for P is
-declared in the private part).
+non-abstract primitive procedure P (even though the overriding procedure for
+P is declared in the private part).
 
 Based on this analysis, let's look again at AI95-00211. This AI deals with
-renamings of 'shall be overridden' subprograms, as shown in the following
+renamings of "shall be overridden" subprograms, as shown in the following
 example:
 
     package Types is
@@ -167,16 +168,16 @@
     end Extensions;
 
 Pr denotes a new view of P, and we know that P will ultimately be overridden.
-The overrider of P will actually provide a body for Pr, too, so there is no
-need for Pr to inherit the 'shall be overridden' property. However, an odd
-consequence of this analysis is that, although Pr occurs before the declaration
-of the override, it is not technically a squirrelling renaming in the sense of
-AARM 8.5.4(8.g).  This seems unnecessarily confusing.
+The overridding declaration of P will actually provide a body for Pr, too, so
+there is no need for Pr to inherit the "shall be overridden" property. However,
+an odd consequence of this analysis is that, although Pr occurs before the
+declaration of the override, it is not technically a squirreling renaming in
+the sense of AARM 8.5.4(8.g).  This seems unnecessarily confusing.
 
 In order to avoid this oddity, it seems appropriate to make the renaming
 illegal (as stated in AI95-00211) but the logic for reaching that conclusion
-in AI95-00211 was incorrect, because of the confusion between 'abstract' and
-'shall be overridden'.
+in AI95-00211 was incorrect, because of the confusion between "abstract" and
+"shall be overridden".
 
 !corrigendum 8.5.4(5/1)
 

Questions? Ask the ACAA Technical Agent