Subject: SC 22 N 3544 - Disposition of Comments Report for ISO/IEC PDTR 19 755, Object finalization for programming language COBOL (Type 2 TR)

From: Matthew Deane <[email-masked]>
Date: Wed, 19 Feb 2003 13:44:46 -0500

ISO/IEC JTC 1/SC22 
Programming languages, their environments and system software interfaces 
Secretariat:  U.S.A.  (ANSI) 
  
ISO/IEC JTC 1/SC22 N3544 
  
TITLE: 
Disposition of Comments Report for ISO/IEC PDTR 19755, Object finalization
for programming language COBOL (Type 2 TR)

DATE ASSIGNED: 
2003-02-19 
  
SOURCE: 
WG 4 Convenor (D. Schricker) 

BACKWARD POINTER: 
  
DOCUMENT TYPE: 
Disposition of Comments Report
 
PROJECT NUMBER: 
22.01.07.01
  
STATUS: 
Disposition of Comments report in response to document SC 22 N3494.   The
text for DTR ballot is contained in N3545.

ACTION IDENTIFIER: 
FYI 
  
DUE DATE: 
  
DISTRIBUTION: 
Text

CROSS REFERENCE: 
N3494 

DISTRIBUTION FORM: 
Def 
  
Address reply to: 
ISO/IEC JTC 1/SC22 Secretariat 
Matt Deane 
ANSI 
25 West 43rd Street 
New York, NY  10036 
Telephone:  (212) 642-4992 
Fax:             (212) 840-2298 
Email:  [email-masked] 

____end of cover page, beginning of document_____

Disposition of Comments Report
PDTR 19755 - Object finalization for programming language COBOL

Date:    February 12, 2003
Source:   Don Schricker, Convener of ISO/IEC JTC 1/SC 22/WG 4 - COBOL

This document presents the Disposition of Comments on SC22 N 3408,
Registration and Approval Ballots for PDTR 19755, Object finalization for
programming language COBOL (Type 2 TR).  The summary of voting is contained
in SC22 N 3494.  

The voting result on the subject of PDTR registration was:

"P" Members supporting registration without comment                   
8 (China, Denmark, Japan, Republic of Korea, Netherlands, Norway, UK, USA)

"P" Members supporting registration with comments              
1 (Germany)        

"P" Members not supporting registration      
0

"P" Members abstaining                    
3 (Austria, Canada, Switzerland)

"P" Members not voting                    
11 (Belgium, Brazil, Czech Republic, Egypt, Finland, Ireland, DPR of Korea,
Romania, Russian Federation, Slovenia, Ukraine)

The voting result on the subject of PDTR was:

"P" Members supporting approval without comment                   
6 (China, Denmark, Republic of Korea, Netherlands, Norway, UK)

"P" Members supporting approval with comments              
3 (Germany, Japan, USA)        

"P" Members not supporting approval       
0

"P" Members abstaining                    
3 (Austria, Canada, Switzerland)

"P" Members not voting                    
11 (Belgium, Brazil, Czech Republic, Egypt, Finland, Ireland, DPR of Korea, 
Romania, Russian Federation, Slovenia, Ukraine)

This document presents the full text of each comment followed by the working
group's disposition.  The change resulting from the resolution of the
comment is briefly summarized in the disposition.  The revised TR is
available at the following web address:
	<http://www.cobolstandard.info/wg4/open/wg4n0170.doc>

The referenced J4 proposals containing the detailed changes are available at
<http://www.cobolportal.com/j4>.

Germany

We have the following comments on this technical report that should be
solved:

1.  Finalization of Factory objects is not yet allowed. This should not only
be mentioned in annex B3 as unresolved technical issue but should be a
syntax rule in 11.6a AUTO-METHOD Paragraph, saying that this paragraph is
only allowed within the OBJECT part of a Class.

WG4 Response:  A rule will be added to explicitly prohibit finalizers in
factories.  (Note that Japan 3 addresses the same issue)  J4/03-0020,
Finalizer TR - Missing Rules (Takagi)

 2.  On  page 11 B.4: We understand this issue but we do not understand what
is unresolved with it, and that gives us some irritation.

WG4 Response:  We agree that there really is no unresolved issue, so this
will be removed from the list of unresolved technical issues.   Notes will
be added to the new rules for MOVE and SET to explain that they prohibit
object resurrection.  A section will be added to the concepts to discuss
object resurrection. J4/03-0035, Finalizer TR - Object Resurrection
(Hubbell)

Japan
[Technical]

1.  There should be a rule that says that the definition of the auto-method
finalizer shall be specified only once in a class definition.

WG4 Response:  This rule will be added.  J4/03-0020, Finalizer TR - Missing
Rules (Takagi)

2.  Page 8, 6.7, Changes to 16, Standard classes, [a].
Since INVOKEFINALIZERS method is intended to trigger resource reclamation,
rules for this method should mention reclamation.  Making objects
unreachable does not mean they will be reclaimed promptly.

WG4 Response:  No technical change will be made for this comment.  The
introductory paragraph for the InvokeFinalizers method will be changed to
remove mention of garbage collection.  Whether a requirement for actual
resource reclamation would cause unacceptable system performance will be
listed as an Unresolved Technical Issue in the next draft of this TR to
invite comment on this issue.  J4/03-0025, Garbage collection and
INVOKEFINALIZERS (Hubbell)

3.  Page 11, Annex B.3, Finalizers in factory object.
Although it says "This proposed draft Technical Report does not provide a
facility to specify a finalizer in the factory definition of a class.", no
rule prohibits specifying a finalizer in the factory definition.  A rule
should be added for this prohibition.

WG4 Response:  A rule will be added to explicitly prohibit finalizers in
factories.  (Germany 1 addresses the same issue and contains the J4
resolution.)  J4/03-0020, Finalizer TR - Missing Rules (Takagi)

USA

1.  We would like to see the document address more fully the problems
associated with asynchronicity with regards to finalization.

WG4 Initial Response:  Further investigation will be done in this area.  The
outcome may be that no change is needed.

WG4 believes that some implementations will need synchronization mechanisms
to avoid side effects in finalizer execution.  Others might not.  We think
that the design of synchronization features should take into account the
complete requirements for the language, and we think that is a larger scope
of work than we can undertake as part of the finalizer TR.

We also think that the experience of implementors in handling
synchronization for finalizers during TR implementation will contribute to a
better standard design than we might achieve in the absence of that
experience.

WG4 Response after investigation and discussion: No change will be made in
this area. 

2.  We would like to see further progress in the resolution of the
unresolved issues in Annex B.

WG4 Response:  The technical issues that are listed will be removed.
Discussion of these issues will be added to Annex C, Concepts.  J4/03-0026,
Unresolved technical issues (Hubbell)