--- a/WeakArray.st	Thu Feb 02 13:13:16 1995 +0100
+++ b/WeakArray.st	Thu Feb 02 13:23:05 1995 +0100
@@ -12,7 +12,7 @@
 
 Array variableSubclass:#WeakArray
        instanceVariableNames:'watcher dependents'
-       classVariableNames:'RegistrationFailedSignal'
+       classVariableNames:'RegistrationFailedSignal AlreadyInitialized'
        poolDictionaries:''
        category:'Collections-Arrayed'
 !
@@ -21,7 +21,7 @@
 COPYRIGHT (c) 1991 by Claus Gittinger
 	      All Rights Reserved
 
-$Header: /cvs/stx/stx/libbasic/WeakArray.st,v 1.7 1994-10-28 01:30:48 claus Exp $
+$Header: /cvs/stx/stx/libbasic/WeakArray.st,v 1.8 1995-02-02 12:23:02 claus Exp $
 '!
 
 !WeakArray class methodsFor:'documentation'!
@@ -42,7 +42,7 @@
 
 version
 "
-$Header: /cvs/stx/stx/libbasic/WeakArray.st,v 1.7 1994-10-28 01:30:48 claus Exp $
+$Header: /cvs/stx/stx/libbasic/WeakArray.st,v 1.8 1995-02-02 12:23:02 claus Exp $
 "
 !
 
@@ -68,21 +68,21 @@
 
     The way in which weakArrays get informed by the runtime system is via
     an interrupt (DisposeInterrupt). The reason for not sending messages
-    directly from the VM is to make it possible, to run the finalization
+    directly from the VM is to make it possible to run the finalization
     code at lower priority or from another class. 
     Also, as a side effect, it is possible to delay finalization by blocking 
-    interrupts
+    interrupts.
 
     This interrupt is cought here and informs the watcher and, if there is
     a dependent, this one gets informed as well (I dont know, which of the
     two mechanisms will survive in the long run - I started with the watcher,
     but now switch to dependencies since they seem to provide more flexibility).
-    Therefore, be prepared, that the watcher mechanism will vanish in the 
-    future.
+    Therefore, be prepared, that the watcher mechanism may vanish in the 
+    future (i.e. use dependencies for your applications).
 
-    NOTICE: weakArray handling add some (small) overhead to the VM (each weakarray
-    is scanner after each GC). It is uncertain, if the current mechanism works well
-    with (say) thousands of weakArrays.
+    NOTICE: WeakArray handling adds some (small) overhead to the VM (each weakarray
+    is scanned after each GC). It is uncertain, if the current mechanism works well
+    with (say) ten-thousands of weakArrays.
 "
 ! !
 
@@ -106,14 +106,18 @@
     "return a new weakArray with size slots"
 
     "This is a kludge: I would like to set WEAK-flag in the classes
-     initialize method, but no order of class-init is defined (yet) ...
-     Therefore it could happen, that a WeakArray is used by other
-     class inits BEFORE this initialize is evaluated. To avoid this,
-     the WEAK bit in the class is set here, when the first WeakArray is 
-     created."
+     initialize method, but (currently) the order in which the class-initialize
+     methods are called for is not defined ...
+     ... therefore it could happen, that a WeakArray is used by other
+     classes initialize method BEFORE this method is evaluated. 
+     To avoid this, the WEAK bit in the class is set here, when the very first 
+     WeakArray is created."
 
-    self flags:(Behavior flagWeakPointers).
-    ObjectMemory disposeInterruptHandler:self.
+    AlreadyInitialized isNil ifTrue:[
+	self flags:(Behavior flagWeakPointers).
+	ObjectMemory disposeInterruptHandler:self.
+	AlreadyInitialized := true
+    ].
 
     ^ (self basicNew:size) registerAsWeakArray
 ! !