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.

@@ -1633,8 +1633,8 @@

Classes are destroyed by the destruction of the class-object using the destroy method of the Object 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 Object, if no super-class is specified. Therefore, if all super-classes are destroyed or removed, the new super-class is Object, not: no @@ -2559,7 +2559,7 @@

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 OvalOffice was derived from the Room class. Without a change to the program each OvalOffice object automatically produces the same filter output as rooms. @@ -2742,7 +2742,7 @@ Trace add Room

messages to all rooms, including all instances of Room´s -sub-classes, are surrounded with a CALL and an EXIT output. With +subclasses, are surrounded with a CALL and an EXIT output. With

   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 @@
   Class OvalOffice::Carpet -superclass ::Carpet
 

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 info instance method:

@@ -4785,7 +4785,7 @@

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).