Subject: Document SC22 N2170 (Retransmittal)

From: "william c. rinehuls" <[email-masked]>
Date: Wed, 19 Jun 1996 12:04:30 -0400 (EDT)

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:  [email-masked]

____________________________________________________________________________

                        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 __________________________