Index: doc/Object.3
===================================================================
diff -u -rc4f449cb353be812ba6502ef8e9587e87881f59b -rf52d344b772763bfd59bc41294e7a45a336b2346
--- doc/Object.3	(.../Object.3)	(revision c4f449cb353be812ba6502ef8e9587e87881f59b)
+++ doc/Object.3	(.../Object.3)	(revision f52d344b772763bfd59bc41294e7a45a336b2346)
@@ -676,7 +676,7 @@
 .CS
 
 
-refuse to overwrite protected method 'destroy'; derive e\&.g\&. a sub-class!
+refuse to overwrite protected method 'destroy'; derive e\&.g\&. a subclass!
 
 .CE
 .IP
Index: doc/Object.man
===================================================================
diff -u -rbee99fc86ef3ae54e20c0912f467d62eca010246 -rf52d344b772763bfd59bc41294e7a45a336b2346
--- doc/Object.man	(.../Object.man)	(revision bee99fc86ef3ae54e20c0912f467d62eca010246)
+++ doc/Object.man	(.../Object.man)	(revision f52d344b772763bfd59bc41294e7a45a336b2346)
@@ -368,7 +368,7 @@
 application-level redefinition. Trying to evaluate the above script snippet yields: 
 
 [example {
-refuse to overwrite protected method 'destroy'; derive e.g. a sub-class!  
+refuse to overwrite protected method 'destroy'; derive e.g. a subclass!
 }]
 
 A custom [method destroy] must be provided as a refinement in a
Index: doc/tutorial2.html
===================================================================
diff -u -r2a955681817e4db4776d7ae904babe8053c5ad74 -rf52d344b772763bfd59bc41294e7a45a336b2346
--- doc/tutorial2.html	(.../tutorial2.html)	(revision 2a955681817e4db4776d7ae904babe8053c5ad74)
+++ doc/tutorial2.html	(.../tutorial2.html)	(revision f52d344b772763bfd59bc41294e7a45a336b2346)
@@ -1589,7 +1589,7 @@
 the first glance. The programmer often can only determine by trial
 which method is found firstly. Than an explicit naming of the class is
 necessary, which means storage of non-local information in
-sub-classes. Often different compilers of one language behave
+subclasses. Often different compilers of one language behave
 differently. All these issues make code reuse difficult. Moreover
 understandability and portability are reduced.
 </P>
@@ -1633,8 +1633,8 @@
 </H3>
 <P>Classes are destroyed by the destruction of the class-object using
 the <tt>destroy</tt> method of the <tt>Object</tt> class. The
-destruction of super-classes does not destroy the sub-classes. The
-super-class is simply removed from the sub-classes' super-class
+destruction of super-classes does not destroy the subclasses. The
+super-class is simply removed from the subclasses' super-class
 lists. All classes have the super-class <tt>Object</tt>, if no
 super-class is specified. Therefore, if all super-classes are
 destroyed or removed, the new super-class is <tt>Object</tt>, not: no
@@ -2559,7 +2559,7 @@
 </pre><P>
 Filters are invoked in registration order. The order may be changed
 by removing them and adding them in new order. Filters are inherited
-by sub-classes. E.g. in the preceding example for the next path, an
+by subclasses. E.g. in the preceding example for the next path, an
 <tt>OvalOffice</tt> was derived from the <tt>Room</tt> class. Without
 a change to the program each <tt>OvalOffice</tt> object automatically
 produces the same filter output as rooms. 
@@ -2742,7 +2742,7 @@
   Trace add Room
 </pre><P>
 messages to all rooms, including all instances of <tt>Room</tt>&acute;s
-sub-classes, are surrounded with a CALL and an EXIT output. With 
+subclasses, are surrounded with a CALL and an EXIT output. With
 </P>
 <pre CLASS="code">
   Trace add Object
@@ -2823,7 +2823,7 @@
 provide all combinations of additional mix-in functionality.
 Furthermore it is possible that the number of additions is unlimited,
 since the additions may produce other additions as side-effects. This
-demonstrates clearly that the sub-class mechanism provides only a
+demonstrates clearly that the subclass mechanism provides only a
 poor mechanism for mix-in of orthogonal functionality. Therefore we
 provide an extension in the form of class-object mixin classes, which are
 added in front of the search precedence of classes. 
@@ -4003,7 +4003,7 @@
   <tt>Class</tt> OvalOffice::Carpet <tt>-superclass</tt> ::Carpet
 </pre><P>
 Nested classes can be used exactly like ordinary classes, a user can
-sub-class it, derive instances, etc. The information about the
+subclass it, derive instances, etc. The information about the
 nesting structure of classes is available through the <tt>info</tt>
 instance method: 
 </P>
@@ -4785,7 +4785,7 @@
 </pre><P>
 All kinds of storage have to implement every method from the
 interface. E.g. a GNU Database Access, a relational database access,
-and several other storage forms may be derived by sub-classing
+and several other storage forms may be derived by subclassing
 (therefore, all conform to the same storage access interface). 
 </P>