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

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

--- ai05s/ai05-0125-1.txt	2010/11/12 05:19:09	1.7
+++ ai05s/ai05-0125-1.txt	2011/02/10 05:40:42	1.8
@@ -1,4 +1,4 @@
-!standard  7.3.1(6)                                10-10-30    AI05-0125-1/02
+!standard  7.3.1(6)                                11-02-09    AI05-0125-1/03
 !standard  8.3(12.3/2)
 !standard  8.3.1(5/2)
 !class Amendment 08-10-20
@@ -87,14 +87,41 @@
 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
+  (see 7.3.1) and is not a homograph of an inherited subprogram that is
+  declared, 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).
 
+  Similarly, if a protected or task type inherits a subprogram that is
+  never declared (and is not a homograph of an inherited subprogram that
+  is declared), whose first parameter is of the synchronized type or is
+  an access parameter designating the type, then if the type has a
+  single entry or protected subprogram with the same defining name and a
+  profile that is type-conformant with the prefixed view of the
+  inherited subprogram, this entry or protected subprogram /implements/
+  the inherited subprogram (for the purposes of dispatching calls), so
+  long as a corresponding dispatching operation of some progenitor is
+  visible at the point of the entry or protected subprogram declaration.
+  The declaration of such an entry or protected subprogram requires an
+  overriding_indicator, which shall be OVERRIDING (see 8.3.1).
+
+    AARM NOTE: Such an inherited subprogram is necessarily a null
+    procedure which was declared in the private part of the package
+    where the associated interface was declared, since private dispatching
+    operations may not be abstract, and null procedures are the only
+    operations of an interface that are not abstract (other than the
+    equality operators!).
+
+    Also note that a single overriding might override two null procedures
+    that are private operations of two separate interfaces. This is fine,
+    because as usual, if two interfaces have operations that are homographs,
+    then it is presumed that these represent the "same" operation in some
+    sense.
+
 Modify 8.3.1(5/2) as follows:
 
     * if the overriding_indicator is OVERRIDING, then the operation
@@ -129,6 +156,13 @@
 visible, no overriding occurs, and if an overriding indicator were given,
 it would have to indicate NOT OVERRIDING.
 
+Note that if there is a visible inherited subprogram which is a
+homograph with the one that is never declared, then the visible
+inherited subprogram is the one being overridden, not the one that is
+never declared.  This ensures compatibility with existing programs that
+override visible operations which happen to be homographs with private
+operations.
+
 !ASIS
 
 The overriding relationship is not currently represented in
@@ -388,5 +422,49 @@
 
 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.
+
+****************************************************************
+
+From: Tucker Taft
+Sent: Wednesday, February  9, 2011  11:13 PM
+
+[Version /03 of the AI was attached - Editor.]
+
+Here is a modest update to AI-125.  It now worries about entries and protected
+subprograms overriding inherited subprograms which are not declared (which are
+necessarily null procedures).  It also worries about the case where there is an
+inherited subprogram that *is* declared which is a homograph of the one that is
+*not* declared. Finally it makes mention of the possibility that a single
+overriding might override two inherited subprograms, neither of which are
+declared.  We consider that as OK, since we already allow a single declaration
+to override two inherited subprograms from different interfaces.
+
+****************************************************************
+
+From: Randy Brukardt
+Sent: Wednesday, February  9, 2011  11:38 PM
+
+> Here is a modest update to AI-125.
+
+I must be dreaming. I actually thought I received some homework from Tucker. :-)
+
+> It now worries about
+> entries and protected subprograms overriding inherited subprograms
+> which are not declared (which are necessarily null procedures).  It
+> also worries about the case where there is an inherited subprogram
+> that *is* declared which is a homograph of the one that is *not*
+> declared.
+> Finally it makes mention of the possibility that a single overriding
+> might override two inherited subprograms, neither of which are
+> declared.  We consider that as OK, since we already allow a single
+> declaration to override two inherited subprograms from different
+> interfaces.
+
+I found the new AARM note midly confusing, since it seems to apply to both of
+the new paragraphs, but it is really only talking about the second one. I was
+trying to figure how it worked in the "normal" case and it didn't make much
+sense.
+
+Perhaps that won't be a problem in the actual AARM.
 
 ****************************************************************

Questions? Ask the ACAA Technical Agent