CVS difference for ais/ai-00211.txt

Differences between 1.2 and version 1.3
Log of other versions for file ais/ai-00211.txt

--- ais/ai-00211.txt	1998/11/18 20:43:39	1.2
+++ ais/ai-00211.txt	1998/11/19 00:16:30	1.3
@@ -1,4 +1,4 @@
-!standard H.3.1     (8)                             98-11-18  AI95-00211/00
+!standard H.3.1     (8)                             98-11-18  AI95-00211/01
 !class ramification 98-11-18
 !status work item 98-11-18
 !priority Medium
@@ -9,11 +9,13 @@
 
 An abstract subprogram can be renamed, and the renamed view is also
 abstract. Such a renaming must appear in a place where the declaration
-of an abstract subprogram would be legal.
+of an abstract subprogram would be legal. Similarly, the "shall be overridden"
+property of 3.9.3(6) applies to a renamed view.
 
 !question 98-11-18
 
-Can an abstract subprogram be renamed? (Yes.)
+Can an abstract subprogram be renamed? (Yes.) Can a subprogram which
+must be overridden in the sense of 3.9.3(6) be renamed? (Yes.)
 
 Consider an example with an abstract parent type and primitive. 8.5.4(8)
 says that the renaming uses the original inherited subprogram, not the
@@ -26,7 +28,7 @@
    package extensions is
       type e is new types.t with ...
       procedure pr (f : e) renames p;  -- renaming of inherited p
-                                       -- Legal? (No.)
+                                       -- Legal? (Yes, but see response.)
       procedure p  (f : e);
    end extensions;
 
@@ -40,7 +42,7 @@
    package extensions is
       type e is new types.t with ...
       function fr return e renames f;  -- renaming of inherited f
-                                       -- Legal? (No.)
+                                       -- Legal? (Yes, but see response.)
       function f  return e;
    end extensions;
 
@@ -51,11 +53,14 @@
 abstract subprograms apply at the point of the renaming (in particular,
 3.9.3(3)).
 
-In the first example, the renaming is illegal by 3.9.3(3), as a
-subprogram primitive for a non-abstract tagged type cannot be abstract.
+Similarly, it is possible (but not useful) to rename an inherited subprogram
+which must be overridden because of the rules of 3.9.3(6). The intent of
+the language is that the "shall be overridden" property also applies to the
+renamed view. Since the renamed view still must be overridden, such a 
+renaming serves no useful purpose.
 
-In the second example, the renaming is legal, but useless, as an overriding
-version must be provided as specified in 3.9.3(6).
+In the both examples, the renaming is legal. However, both examples are
+illegal as written since the overridding required by 3.9.3(6) is absent.
 
 
 !appendix 98-11-18
@@ -167,3 +172,74 @@
 
 ****************************************************
 
+From: 	Todd Allen[SMTP:todd@tawny.ccur.com]
+Sent: 	Wednesday, November 18, 1998 8:47 AM
+To: 	Randy Brukardt
+Cc: 	Ada Commentaries
+Subject: 	Re: Renames of inherited abstract subprograms
+
+!topic Renames of inherited abstract subprograms
+!reference RM95-3.9.3(4-6)
+!reference RM95-8.5.4(8)
+!reference RM95-3.9.3(1)
+!from Todd Allen 98-11-18 [todd@TAWNY.CCUR.COM]
+!keywords subprogram renames, inherited abstract subprograms
+!reference 1998-15932.a Todd Allen  1998-11-10
+!reference 1998-15935.a Todd Allen  1998-11-18
+!discussion
+
+I agree that renaming of abstract subprograms is an issue, and it's related
+to my commentary.  But it's not quite the point I was trying to make.
+
+If a parent tagged type has an abstract primitive subprogram, the inherited
+subprograms for any type extensions are not abstract.  This case is excluded
+from 3.9.3(5), and 3.9.3(6) merely says that any subprograms inherited from
+abstract subprograms must be overridden, not that they are abstract.  As a
+result, neither of the renaming declarations in my examples is renaming an
+abstract subprogram.
+
+If the clause 3.9.3(5) were changed to include tagged types, then either of
+Randy's interpretations could be applied.  Otherwise, the case of a rename of
+a subprogram inherited from an abstract primitive subprogram would have to be
+handled separately.
+
+-- 
+Todd Allen
+Concurrent Computer Corporation
+
+****************************************************
+
+!topic Renames of inherited abstract subprograms
+!reference RM95-3.9.3(4-6)
+!reference RM95-8.5.4(8)
+!reference RM95-3.9.3(1)
+!from Randy Brukardt 98-11-18
+!keywords subprogram renames, inherited abstract subprograms
+!reference 1998-15932.a Todd Allen  1998-11-10
+!reference 1998-15934.a Randy Brukardt  1998-11-18
+!reference 1998-15935.a Todd Allen  1998-11-18
+!reference 1998-15936.a Randy Brukardt  1998-11-18
+!discussion
+
+Todd says:
+
+>If a parent tagged type has an abstract primitive subprogram, the inherited
+>subprograms for any type extensions are not abstract.  This case is excluded
+>from 3.9.3(5), and 3.9.3(6) merely says that any subprograms inherited from
+>abstract subprograms must be overridden, not that they are abstract.  As a
+>result, neither of the renaming declarations in my examples is renaming an
+>abstract subprogram.
+
+I see your point, but I still don't think there is a real problem with the standard.
+Assuming that the operative principle for renames is that the new view preserves
+the properties of the original view (such as abstractness), we still have no
+problem.
+
+In the abstract subprogram case, a renames would create an abstract view.
+In Todd's example, a renames would preserve the "must be overridden" property.
+Therefore, both of Todd's examples are illegal because the overriding isn't given.
+(It's still a ramification.)
+
+					Randy.
+
+****************************************************

Questions? Ask the ACAA Technical Agent