CVS difference for ais/ai-00193.txt

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

--- ais/ai-00193.txt	1999/03/22 22:33:25	1.3
+++ ais/ai-00193.txt	1999/04/15 16:54:17	1.4
@@ -1,13 +1,14 @@
-!standard 07.06.01 (04)                               99-03-21  AI95-00193/03
+!standard 07.06.01 (04)                               99-04-15  AI95-00193/04
 !standard 07.06.01 (16)
 !class binding interpretation 97-08-19
+!status ARG approved (with editiorial changes) 6-0-3 99-03-25
 !status work item 98-04-02
 !status received 97-08-19
 !priority High
 !difficulty Hard
 !subject Classwide Adjust and exceptions
 
-!summary 99-03-21
+!summary
 
 For a controlled object (including a component) that is initialized
 explicitly by assignment (possibly to an enclosing object), if its Adjust
@@ -15,7 +16,8 @@
 it is not specified by the language whether the object is finalized.
 If the object is initialized by assignment from an aggregate, its
 Adjust procedure is not invoked (per AI-00083 and AI-00197), but it is
-finalized.  If it is initialized by assignment from something other
+finalized if and only if the initialization is successful.
+If it is initialized by assignment from something other
 than an aggregate, but its Adjust procedure is not invoked at all
 because initialization fails before that point, then the object is
 not finalized.
@@ -24,17 +26,17 @@
 finalized unless default initialization completes successfully, i.e.
 without propagating an exception.
 
-The definition of "adjustments due to be performed" is relaxed
-for an assignment operation used for initialization, as opposed to one
-used in an assignment statement.
+For an Adjust invoked as part of initialization, if it propagates
+an exception, no other adjustments need be performed prior to
+raising Program_Error.
 
-!question 99-03-21
+!question
 
 If an object that is initialized by assignment fails during
 an Adjust operation, should the object nevertheless be finalized?
 (This AI recommends that this be unspecified.)
 
-!recommendation 99-03-21
+!recommendation
 
 Paragraph 7.6.1(4) says:
 
@@ -59,10 +61,10 @@
 all controlled subcomponents are going to be finalized.
 
 
-!wording 98-04-09
+!wording
 
 
-!discussion 99-03-21
+!discussion
 
 When an object (including a component) is initialized by an assignment
 other than from an aggregate, the Adjust operation is invoked.
@@ -82,7 +84,7 @@
 of which parts failed and which succeeded, and only finalize those
 whose Adjust succeeded.  Note that if some of the Adjust operations
 had failed in an assignment statement, all parts would ultimately
-still be finalized when the scope is existed.
+still be finalized when the scope is exited and the master is left.
 
 One of the important goals of the finalization model with respect to
 exceptions (paragraphs 7.6.1(14-18)) is that if one controlled
@@ -113,7 +115,7 @@
 Adjust fails, so long as those components which have never been
 adjusted are not finalized.
 
-!appendix 97-08-19
+!appendix
 
 !section 7.6.1(4)
 !subject Classwide Adjust and exceptions
@@ -175,7 +177,7 @@
 that was already "hosed" to begin with.
 
 Another possibility is to leave things as we have them now, which
-means no part is finalized if any parts fail.  The problem with that 
+means no part is finalized if any parts fail.  The problem with that
 is that one messed up controlled abstraction can have the effect
 of progressively messing up any other controlled abstraction, just
 by both being used as components of the same object.
@@ -274,12 +276,12 @@
 
     (No hole, but overly complex): Finalize exactly those for whom
     Adjust succeeded.
-    
-> The problem is, if the Adjust_Whole_Object propagates Program_Error, 
+
+> The problem is, if the Adjust_Whole_Object propagates Program_Error,
 > then we don't register the whole object for finalization.  We also
 > don't register any part of the object for finalization, even
 > those parts that were successfully adjusted, since we don't have
-> any record of which parts succeeded versus which parts failed.  
+> any record of which parts succeeded versus which parts failed.
 
 This seems bad.
 
@@ -287,7 +289,7 @@
       ^^^^^^^^^^^^^^^
 > Adjust_Whole_Object_For_Initialization routine for each tagged
 > type, which rather than just raising Program_Error when one or more
-> parts fail to adjust, will also finalize any parts that were successfully 
+> parts fail to adjust, will also finalize any parts that were successfully
 > adjusted before raising Program_Error.
 
 That seems like a misuse of the term "straightforward", to me.  ;-)
@@ -307,12 +309,12 @@
 
 >...  That could happen as a result of an assignment
 > statement anyway, and the only thing being corrupted is a part
-> that was already "hosed" to begin with.  
+> that was already "hosed" to begin with.
 
 Right.
 
-> Another possibility is to leave things as we have them now, which 
-> means no part is finalized if any parts fail.  The problem with that 
+> Another possibility is to leave things as we have them now, which
+> means no part is finalized if any parts fail.  The problem with that
 > is that one messed up controlled abstraction can have the effect
 > of progressively messing up any other controlled abstraction, just
 > by both being used as components of the same object.
@@ -328,7 +330,7 @@
 > In the spirit of AI95-179, the ARG might say that exceptions inside
 > Adjust or Finalize are bad news anyway, and we should permit some
 > relaxation of 7.6.1(4) in one direction or the other.
-> 
+>
 > Alternatively, the ARG says that the independence of controlled abstractions
 > is quite important, and we should minimize failure coupling between
 > them even if they appear as components of the same object, and
@@ -386,13 +388,13 @@
 !reference 1997-15760.a Randy Brukardt  1997-7-25>>
 !discussion
 
->The problem is, if the Adjust_Whole_Object propagates Program_Error, 
+>The problem is, if the Adjust_Whole_Object propagates Program_Error,
 >then we don't register the whole object for finalization.  We also
 >don't register any part of the object for finalization, even
 >those parts that were successfully adjusted, since we don't have
->any record of which parts succeeded versus which parts failed.  
->This seems to violate the requirement of 7.6.1(4) which says 
->that any object that is successfully initialized must be finalized.  
+>any record of which parts succeeded versus which parts failed.
+>This seems to violate the requirement of 7.6.1(4) which says
+>that any object that is successfully initialized must be finalized.
 
 >Is there some way to have a single Adjust_Whole_Object routine
 >per tagged type?
@@ -404,10 +406,10 @@
 >and then live with the fact that we are going to finalize parts
 >whose Adjust failed.  That could happen as a result of an assignment
 >statement anyway, and the only thing being corrupted is a part
->that was already "hosed" to begin with.  
+>that was already "hosed" to begin with.
 
->Another possibility is to leave things as we have them now, which 
->means no part is finalized if any parts fail.  The problem with that 
+>Another possibility is to leave things as we have them now, which
+>means no part is finalized if any parts fail.  The problem with that
 >is that one messed up controlled abstraction can have the effect
 >of progressively messing up any other controlled abstraction, just
 >by both being used as components of the same object.
@@ -504,7 +506,7 @@
 !discussion
 
 > ...
-> I think this logic is correct.  Therefore, we don't even need a rule change 
+> I think this logic is correct.  Therefore, we don't even need a rule change
 > to be
 > allowed to implement this sensibly.  Certainly, my approach is a lot easier to
 > implement than the one suggested by Tucker, and it does not contain any hole.
@@ -520,8 +522,8 @@
 (And save the user some code space and compile-time.)
 
 If we are allowed to Finalize fields that fail during Adjust, then
-I could use a single routine that would raise one of two different 
-exceptions, one special one meaning that there was at least one success, 
+I could use a single routine that would raise one of two different
+exceptions, one special one meaning that there was at least one success,
 and any other meaning that there was no successful Adjust.
 
 > BTW, I have not received any of this discussion via the comment repeater, so I
@@ -563,8 +565,8 @@
 than two.
 
 > If we are allowed to Finalize fields that fail during Adjust, then
-> I could use a single routine that would raise one of two different 
-> exceptions, one special one meaning that there was at least one success, 
+> I could use a single routine that would raise one of two different
+> exceptions, one special one meaning that there was at least one success,
 > and any other meaning that there was no successful Adjust.
 
 I don't understand what you mean, here.  I see one exception --
@@ -641,7 +643,7 @@
 
 > !standard 07.06.01 (04)                               98-04-09  AI95-00193/01
 ...
-> still be finalized when the scope is existed.  
+> still be finalized when the scope is existed.
                               ^^^^^^^^^^^^^^^^
 You misspelt "master is left".  ;-)
 
@@ -673,13 +675,13 @@
 > second controlled component is not "due to be performed" just because
 > the first controlled component's adjust operation has been
 > invoked.  By contrast, if such a composite object is initialized
-> as a whole by assignment, then the adjust operations of all of its 
-> controlled parts are "due to be performed" as soon as the bytes 
-> representing the source (right-hand-side) of the assignment operation 
+> as a whole by assignment, then the adjust operations of all of its
+> controlled parts are "due to be performed" as soon as the bytes
+> representing the source (right-hand-side) of the assignment operation
 > are copied on to the composite object being initialized.
 > ...
 
-I'm not sure I buy this rule any more.  There seems no harm in 
+I'm not sure I buy this rule any more.  There seems no harm in
 stopping after the first failing Adjust operation in the case of
 an assignment operation used as part of initialization, so long
 as only parts for which Adjust has been invoked are in fact finalized.
@@ -687,12 +689,12 @@
 In an assignment statement, the whole object is eventually going
 to be finalized, so clearly you want to go ahead and do all the
 Adjusts for parts that have been copied onto, even if one of them fails.
-For initialization, it seems permissible to conceptuallly do component by 
+For initialization, it seems permissible to conceptuallly do component by
 component assignment/adjustment, even if the implementation starts
 by doing a block copy into the uninitialized storage, so long
 as parts that have not been adjusted are not finalized.
 
-So all in all, my attempt to "clarify" what is meant by 
+So all in all, my attempt to "clarify" what is meant by
 "adjustments due to be performed" should probably be ignored.
 There is perhaps something we could say to clarify the
 intent of "due to be performed," but I am too lazy to figure

Questions? Ask the ACAA Technical Agent