CVS difference for ai05s/ai05-0027-1.txt
--- ai05s/ai05-0027-1.txt 2007/01/13 05:25:56 1.3
+++ ai05s/ai05-0027-1.txt 2007/10/31 02:24:49 1.4
@@ -1,4 +1,7 @@
-!standard A.18.2(238/2) 06-12-13 AI05-0027-1/02
+!standard A.18.2(239/2) 07-10-28 AI05-0027-1/03
!class binding interpretation 06-11-13
!status work item 06-11-13
!status received 06-11-03
@@ -6,22 +9,60 @@
!subject Behavior of containers operations when passed finalized container objects
+If an operation is passed a container object that has been finalized,
+it is a bounded error. If the operation is read-only, then either
+the operation proceeds as though the container were empty, or
+Constraint_Error or Program_Error is raised.
+If a finalized container is passed to an operation that would update
+the container, Constraint_Error or Program_Error is raised.
+What happens in container operations when passed a finalized container object?
+Add the following after A.18.2(239):
+ It is a bounded error to call any subprogram declared in Containers.Vectors
+ when the associated container has been finalized. If the operation takes
+ Container as an IN OUT parameter, then it raises Constraint_Error or
+ Program_Error. Otherwise, the operation either proceeds as it would
+ for an empty container, or it raises Constraint_Error or Program_Error.
+Make corresponding additions to all other container packages,
+after A.18.3(152), after A.18.4(75) [needs "Bounded Error" label
+as well], and after A.18.7(96) [needs "Bounded Error" label].
+It requires some circumlocution (though see the example for a plausible
+situation) to create a situation where an operation can be applied to a
+finalized container. Nevertheless, we don't want such an operation
+to de-finalize the container, and thereby create storage
+leaks or worse. Hence, we do not allow any operation that updates the
+container to proceed, and any other operation either raises an exception,
+or proceeds as though the container were empty. This minimizes any
+distributed overhead associated with handling the finalized case (because
+all non-updating operations need not distinguish a finalized state
+from an empty state), while ensuring that no storage leak or potentially
+erroneous execution is introduced by such "late" operations.
+We allow Constraint_Error rather than Program_Error for efficiency reasons as
+well, since many of the operations that attempt to update an empty
+container will already raise Constraint_Error. It is only the updating
+operations that allow for the container to start out empty that will need an
+explicit check for the finalized state.
+We have suggesting adding this paragraph *before* the discussion of ambiguous
+cursors, as we want that discussion to flow right into the discussion of
Questions? Ask the ACAA Technical Agent