CVS difference for ai12s/ai12-0042-1.txt

Differences between 1.16 and version 1.17
Log of other versions for file ai12s/ai12-0042-1.txt

--- ai12s/ai12-0042-1.txt	2014/07/31 02:09:33	1.16
+++ ai12s/ai12-0042-1.txt	2014/09/30 02:25:58	1.17
@@ -1,4 +1,4 @@
-!standard 7.3.2(6/3)                                 14-07-22    AI12-0042-1/10
+!standard 7.3.2(6/3)                                 14-09-29    AI12-0042-1/11
 !standard 7.3.2(17/3)
 !standard 7.3.2(18/3)
 !standard 7.3.2(19/3)
@@ -99,7 +99,7 @@
        operation. (An example of such a case is given below.)
 
        In such a case, the private operation would not be expected to
-       to maintain the invariant (as it is inside the checking boundary).
+       maintain the invariant (as it is inside the checking boundary).
        However, the inherited routine would be required to maintain the
        invariant (as it is now on the checking boundary). We require
        overriding (or abstractness) in the case of inherited subprograms that
@@ -132,15 +132,13 @@
 We considered the more general issue of invariants that apply to record
 extensions. This can happen two ways. One is a Type_Invariant'Class inherited
 into a record extension. Similarly, invariants can be added to private
-extensions of record types that have visible components. In each of these
-cases, the visible components can be modified independent of the package
-boundaries, which could make the invariant False. The checking for type
+extensions of record types that have visible components. The checking for type
 invariants was designed to catch virtually all cases where the objects
 cross the package boundaries. When there are visible components, this model
-breaks down as the visible components can be modified independent of the
+breaks down as the visible components can be modified independently of the
 package boundaries, which could make the invariant False without detection.
 Both cases could be prevented with Legality Rules (as we do not allow
-class-wide invariants to be hidden). We decided its not worth preventing such
+class-wide invariants to be hidden). We decided it's not worth preventing such
 things, even with the possibility of misuse.
 
 Similarly, there are other holes in the checking represented by type

Questions? Ask the ACAA Technical Agent