From: Jean Stride <[email-masked]>
Date: 23 May 96 05:06:23 EDT

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.

___________________________________________________________________________
FROM:  Michelle Maas
To:  Bill Rinehuls
Subject:  FW: US Vote on SC22 N 2068
Date:  Wednesday, may 29, 1996 2:13PM

Bill,

Please consider this E-Mail message as the USNB response to document
JTC 1/SC22 N2068 - CD Registration Ballot for:  Object Oriented Extensions
for Modula-2

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 __________________________