CVS difference for ais/ai-00252.txt

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

--- ais/ai-00252.txt	2003/07/26 03:26:01	1.6
+++ ais/ai-00252.txt	2003/09/27 23:07:03	1.7
@@ -1,4 +1,4 @@
-!standard 04.01.03 (05)                               03-06-22  AI95-00252/04
+!standard 04.01.03 (05)                               03-09-27  AI95-00252/05
 !class amendment 00-12-04
 !status work item 00-12-04
 !status received 00-12-04
@@ -62,7 +62,7 @@
 case, the package where the access type itself is declared is irrelevant.
 
 As a final addition, if the object is aliased, interpretations where 'Access
-would be needed after the object name are considered.  That is, even if the
+would be needed after the object name are considered. That is, even if the
 prefix is not of an access type, operations with the first parameter being an
 access parameter designating the type of the prefix are considered. This would
 mean that access parameters can be used in general in primitives, without
@@ -92,23 +92,35 @@
     or is an access parameter designating a tagged type.
 
     The prefix (after any implicit dereference) shall resolve to denote an
-    object of a specific tagged type T or class-wide type T'Class.  The
+    object or value of a specific tagged type T or class-wide type T'Class. The
     selector_name shall resolve to denote a subprogram declared immediately
-    within the region in which an ancestor of the type T is declared.  The
-    first formal parameter of the subprogram shall be of type T, or a
-    class-wide type that covers T, or an access parameter designating one of
-    these types.  The selected_component denotes a view of this subprogram
-    that omits the first formal parameter, and has convention Intrinsic.
+    within the region in which an ancestor of the type T is declared. The first
+    formal parameter of the subprogram shall be of type T, or a class-wide type
+    that covers T, or an access parameter designating one of these types. The
+    designator of the subprogram shall not be the same as that of a component
+    of the tagged type visible at the point of the selected_component. The
+    selected_component denotes a view of this subprogram that omits the first
+    formal parameter, and has convention Intrinsic.
 
 Add the following after para 4.1.3(15) of dynamic semantics:
 
     For a selected_component with a tagged prefix and selector that denotes a
-    subprogram, a call on the view denoted by the selected_component
-    is equivalent to a call on the underlying subprogram with the first actual
-    parameter being provided by the object denoted by the prefix (or the Access
-    attribute of this object if the first formal is an access parameter), and
-    the remaining actual parameters given by the actual_parameter_part, if any.
+    subprogram, a call on the view denoted by the selected_component is
+    equivalent to a call on the underlying subprogram with the first actual
+    parameter being provided by the object or value denoted by the prefix (or
+    the Access attribute of this object or value if the first formal is an
+    access parameter), and the remaining actual parameters given by the
+    actual_parameter_part, if any.
+
+Add the following after 6.3.1(10):
+
+  * the view of a subprogram denoted by a selected_component whose prefix
+    denotes an object or value of a tagged type, and whose selector_name
+    denotes a subprogram operating on the type (see 4.1.3).
 
+  [NOTE: This paragraph is officially redundant with 4.1.3(9) and so
+   could be in brackets in the AARM.]
+
 !discussion
 
 This AI grew out of an issue identified by Erhard Ploedereder and his graduate
@@ -124,14 +136,15 @@
 significantly add to the confusion.
 
 We considered an Object'Operation(...) syntax, but that was felt to introduce
-possible conflicts with implementation-dependent attributes.  Also, the "."
+possible conflicts with implementation-dependent attributes. Also, the "."
 notation had the additional nice feature that a primitive function could be
 used to effectively provide a "read only" component, with the familiar "."
 syntax. Also, using the "." notation allows primitives defined outside a
 protected or a task type to be called in the same "obj.operation" notation
 used for entries and protected subprograms. This unifies these two kinds of
 operations, which from a user perspective are both "fundamental" operations
-of the synchronizing types.
+of the synchronizing types. [However, this unification is now irrelevant
+since the proposal is restricted to tagged types.]
 
 We considered only making primitive operations visible, but there are
 situations where an abstraction uses a classwide operation very much like a
@@ -673,5 +686,25 @@
 a use of the tagged type. Instead of dispatching when procedures are
 called, the programmer explicitly specifies the subrecord by gluing on
 extra text after a dot.
+
+****************************************************************
+
+From: Tucker Taft
+Sent: Saturday, September 27, 2003  4:11 PM
+
+Here is an update to AI 252.  Not much change (Randy
+already incorporated some of the changes from Toulouse).
+I added a rule to disallow object.op if "op" is the name
+of a visible component of "object."  I also added
+a paragraph to 6.3.1 to include object.op as an example
+of a subprogram with an intrinsic convention.
+Finally, I changed "object" to "object or value" to
+be consistent with other paragraphs in 4.1.3, and to cover the
+weird cases where the prefix is not officially an
+"object" (e.g. my_array_type(tagged_array)(2) is a
+"value" rather than an "object" -- this distinction is
+pretty silly at this point).
+
+[This is version /05 - ED.]
 
 ****************************************************************

Questions? Ask the ACAA Technical Agent