From rinehuls@access.digex.net Wed Jun 19 18:04:38 1996 Received: from access2.digex.net (qlrhmEbBUV1EY@access2.digex.net [205.197.245.193]) by dkuug.dk (8.6.12/8.6.12) with ESMTP id SAA23356 for ; Wed, 19 Jun 1996 18:04:36 +0200 Received: from localhost (rinehuls@localhost) by access2.digex.net (8.6.12/8.6.12) with SMTP id MAA11272 ; for ; Wed, 19 Jun 1996 12:04:31 -0400 Date: Wed, 19 Jun 1996 12:04:30 -0400 (EDT) From: "william c. rinehuls" X-Sender: rinehuls@access2.digex.net To: sc22docs@dkuug.dk Subject: Document SC22 N2170 (Retransmittal) Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Note: Something went awry in the transmittal of SC22 N2170 yesterday. (At least in the version that came back to me.) So I am retransmitting it - hopefully complete this time. Bill Rinehuls ___________________________________________________________________________ ISO/IEC JTC 1/SC22 Programming languages, their environments and system software interfaces Secretariat: U.S.A. (ANSI) ISO/IEC JTC 1/SC22 N2170 June 1996 TITLE: Summary of Voting on CD Registration for: Object Oriented Extgensions for Modula-2 SOURCE: Secretariat, ISO/IEC JTC 1/SC22 WORK ITEM: JTC 1.22.18.02 STATUS: N/A CROSS REFERENCE: SC22 N2068 DOCUMENT TYPE: Summary of Voting ACTION: The CD has been registered as 10514-3. To SC22 Member Bodies for information. To WG13 for preparation of a Disposition of Comments Report and a recommendation on the further processing of the document. Address reply to: ISO/IEC JTC 1/SC22 Secretariat William C. Rinehuls 8457 Rushing Creek Court Springfield, VA 22153 USA Tel: +1 (703) 912-9680 Fax: +1 (703) 912-2973 email: rinehuls@access.digex.net ____________________________________________________________________________ SUMMARY OF VOTING ON Letter Ballot Reference No: SC22 N2068 Issued by: JTC 1/SC22 Circulation Date: 1996-02-14 Closing Date: 1996-05-30 SUBJECT: CD Registration for: Object Oriented Extensions for Modula-2 The following responses have been received on the subject of registration: "P" Members supporting registration without comments: 9 "P" Members supporting registration with comments: 2 "P" Members not supporting registration: 3 "P" Members abstaining: 3 "P" Members not voting: 4 Secretariat Action: The CD Has been registered as CD 10514-3. The comment accompanying the abstention vote from Sweden was: "Due to lack of expert resources". The comments accompanying the negative votes from the United Kingdom and the USA, and the comments accompanying the affirmative votes from Austria and the Netherlands have been forwarded to SC22/WG13 for preparation of a Disposition of Comments Report and a recommendation on the further pro- cessing of the CD. ____________________________________________________________________________ ISO/IEC JTC1/SC22 LETTER BALLOT SUMMARY PROJECT NO: JTC1.22.18.02 SUBJECT: CD Registration for: Object Oriented Extensions for Modula-2 Reference Document No: N2068 Ballot Document No: N2068 Circulation Date: 02-14-1996 Closing Date: 05-30-1996 Circulated To: SC22 P, L Circulated By: Secretariat SUMMARY OF VOTING AND COMMENTS RECEIVED Approve Disapprove Abstain Comments Not Voting 'P' Members Australia (X) ( ) ( ) ( ) ( ) Austria (X) ( ) ( ) (X) ( ) Belgium ( ) ( ) ( ) ( ) (X) Brazil (X) ( ) ( ) ( ) ( ) Canada (X) ( ) ( ) ( ) ( ) China ( ) ( ) ( ) ( ) (X) Czech Republic (X) ( ) ( ) ( ) ( ) Denmark (X) ( ) ( ) ( ) ( ) Egypt ( ) ( ) ( ) ( ) (X) Finland (X) ( ) ( ) ( ) ( ) France ( ) ( ) (X) ( ) ( ) Germany ( ) (X) ( ) (X) ( ) Japan ( ) ( ) (X) ( ) ( ) Netherlands (X) ( ) ( ) (X) ( ) Romania ( ) ( ) ( ) ( ) (X) Slovenia (X) ( ) ( ) ( ) ( ) Sweden ( ) ( ) (X) (X) ( ) Switzerland (X) ( ) ( ) ( ) ( ) UK ( ) (X) ( ) (X) ( ) Ukraine (X) ( ) ( ) ( ) ( ) USA ( ) (X) ( ) (X) ( ) 'O' Members Argentina ( ) ( ) ( ) ( ) ( ) Bulgaria ( ) ( ) ( ) ( ) ( ) Cuba ( ) ( ) ( ) ( ) ( ) Greece ( ) ( ) ( ) ( ) ( ) Hungary ( ) ( ) ( ) ( ) ( ) Iceland ( ) ( ) ( ) ( ) ( ) India ( ) ( ) ( ) ( ) ( ) Indonesia ( ) ( ) ( ) ( ) ( ) Italy ( ) ( ) ( ) ( ) ( ) Korea Rep (X) ( ) ( ) ( ) ( ) New Zealand ( ) ( ) ( ) ( ) ( ) Norway ( ) ( ) ( ) ( ) ( ) Poland ( ) ( ) ( ) ( ) ( ) Portugal ( ) ( ) ( ) ( ) ( ) Russian fed ( ) ( ) ( ) ( ) ( ) Singapore ( ) ( ) ( ) ( ) ( ) Thailand ( ) ( ) ( ) ( ) ( ) Turkey ( ) ( ) ( ) ( ) ( ) Yugoslavia ( ) ( ) ( ) ( ) ( ) __________________________________________________________________________ Comments Accompanying Austrian Vote: "Yes with comments: It seems questionable, to say the least, if the additional complexity introduced by "safe"/"UNSAFE" modules is worth the effort, given that it seems very few programs would really contain only safe modules in "real world" application, and that even "safe" modules may break in the presence of unsafe ones. Is there sufficient rationale and support for this feature, or should it just be dropped? The procedure COROUTINES.DISPOSECOROUTINE (section 6.8.6) seems confusing. Why is there a parameter, and why is it a VAR parameter? Could an example be provided? ___________________________________________________________________________ Comments Accompanying Netherlands Vote: "There are some difficulties understanding the procedure DISPOSECOROUTINE in the module COROUTINES: The module has a parameter, which means that _ any _ coroutine may be 'aborted' this way. It is unclear why this is. Could some rationale and examples be given? Will objects be finalized during abortion? The parameter is a VAR-parameter. What will be the value of the actual after the operation has taken place? Will the RETURN-FROM-COROUTINE exception be raised during abortion? ___________________________________________________________________________ COMMENTS ACCOMPANYING THE VOTE FROM GERMANY OPPOSING REGISTRATION WG13, CD Registration of SC 22 N 2068, deadline 1996-05-30, Object oriented extensions for Modula-2: We do not support this registration unless the following objections are resolved. (Resolution of these objections changes our vote to YES.) The concept of safe and unsafe modules with all its derived rules introduces a lot of complexity into Object Oriented Modula-2. As the vast majority of real life programs will be anyway "unsafe" due to the many limitations of "save" modules, and as the concept suggests a safety that it does not really deliver, the DIN experts suggest removal of the classification of modules into safe and unsafe modules. ____________________________________________________________________________ COMMENTS ACCOMPANYING UNITED KINGDOM VOTE OPPOSING REGISTRATION N2068 CD Registration Ballot (Object-oriented extensions) Unless the following two objections are resolved: 1) Whilst considering the subject of when/if the finalisation code of traced objects should be performed, a problem has been identified involving the interaction between this and module finalisation, which applies equally to untraced objects. This problem is illustrated by the following example: DEFINITION MODULE A; CLASS Class1; ... END Class1; VAR CurrentObject : Class1; END A. IMPLEMENTATION MODULE A; CLASS Class1; ... END Class1; BEGIN CurrentObject:=EMPTY FINALLY IF CurrentObject <> EMPTY THEN DESTROY(CurrentObject) END END A. DEFINITION MODULE B; PROCEDURE Proc1(...); PROCEDURE Proc2(...); END B. IMPLEMENTATION MODULE B; VAR InternalState : SomeType; PROCEDURE Proc1(...); BEGIN (* Uses InternalState *) END Proc1; PROCEDURE Proc2(...); BEGIN (* Uses InternalState *) END Proc2; BEGIN (* Initialise InternalState *) FINALLY (* Finalise InternalState *) END B.. MODULE C; FROM A IMPORT Class1, CurrentObject; FROM B IMPORT Proc1, Proc2; CLASS Class2; INHERIT Class1; BEGIN Proc1 FINALLY Proc2 END Class2; VAR MyObject : Class2; BEGIN CREATE(MyObject); CurrentObject:=MyObject END C. If the module initialisation order is A, B, C, then the finalisation order is C, B, A. This means that procedures from module B should not be called from the finalisation part of module A. However, when CurrentObject is destroyed in this example, it contains an object of class Class2, whose finalisation code contains a call to a procedure from module B. To demonstrate that this is not just an academic point, consider module B to be an interface to the host filing system (with Proc1 being the open file routine and Proc2 being the close file routine). The module may well keep a list of open files and close them during finalisation. If objects of class Class2 make use of a file (e.g. they keep a log file), then the above situation could easily occur. 2) The panel is concerned that there should be a clean, sensible, way to introduce value-based objects in future work. The following comments also pertain: 3) The note in 6.8.1 on Static Semantics should be changed to: 'If a definition module is unsafe its implicit import into its implementation module will require that module to be tagged as unsafe.' 4) The use of the keyword SAFE is open to misinterpretation. The Panel urges WG13 to seek a more appropriate alternative but supports wholeheartedly the concept it introduces. 5) In traditional Modula-2 the keyword POINTER is used to indicate a reference to an entity, and its absence to indicate a value. The Panel remains concerned that this distinction will be blurred by the current proposal. 6) There appears to be an overlap between this proposal and the system-programming proposal. ___________________________________________________________________________ COMMENTS ACCOMPANYING THE USA VOTE OPPOSING REGISTRATION The USNB DISAPPROVES the CD Registration for the following reason: As the USNB had indicated in its earlier balloting on what is now ISO/IEC 10514-1, Programming Languages, Modula-2, the USNB believes that International Standard is badly flowed; accordingly, extensions to that International Standard are inappropriate. Best regards Michelle Maas For the US P-member of JTC 1/SC22 ____________________ end of document N 2170 __________________________