Index: xotcl/doc/tutorial.html
===================================================================
diff -u -r78e82b3563a644f2df47320eacc693f1b788b03c -rbb3c756fb47517596b9dbcb4e580aa1212827b41
--- xotcl/doc/tutorial.html	(.../tutorial.html)	(revision 78e82b3563a644f2df47320eacc693f1b788b03c)
+++ xotcl/doc/tutorial.html	(.../tutorial.html)	(revision bb3c756fb47517596b9dbcb4e580aa1212827b41)
@@ -1,10 +1,10 @@
 <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
-<!-- $Id: tutorial.html,v 1.12 2006/02/18 22:17:33 neumann Exp $ -->
+<!-- $Id: tutorial.html,v 1.13 2006/09/14 06:36:02 neumann Exp $ -->
 <HTML>
 <HEAD>
 	<TITLE>XOTcl - Tutorial</TITLE>
 	<META NAME="AUTHOR" CONTENT="Gustaf Neumann and Uwe Zdun">
-	<META NAME="DOCNUMBER" CONTENT="1.4.0">
+	<META NAME="DOCNUMBER" CONTENT="1.5.0">
 	<META NAME="CHANGEDBY" CONTENT="Gustaf Neumann">
 <STYLE>
 BODY	{
@@ -27,7 +27,7 @@
 	MARGIN-BOTTOM: 15px;
 }
 pre em {
-    	font-family: cursive;
+    	/*font-family: cursive;*/
 	color: #888888;
 }
 pre tt {
@@ -59,7 +59,7 @@
 			<IMG SRC="logo-100.jpg" NAME="Graphic1" ALIGN=RIGHT WIDTH=102 HEIGHT=42 BORDER=0></TD>
 	</TR>
 </TABLE>
-<p align=right>Version: 1.3.9</p>
+<p align=right>Version: 1.5.0</p>
 
 <UL>
 	<LI>
@@ -98,7 +98,7 @@
 	      Relationships</A> 
 		<LI><A HREF="#meta-classes">Meta-Classes</A>
                 <LI><A HREF="#destroy-logic">Create, Destroy, and Recreate Methods</A>
-	        <LI><A HREF="#non-pos-args">Non-positional Arguments</A>
+	        <LI><A HREF="#non-pos-args">Methods with Non-Positional Arguments</A>
 	</UL>
         </P>
 	<LI><P STYLE="margin-bottom: 0in"><A HREF="#interceptors">Message
@@ -107,22 +107,46 @@
         <UL>
                 <LI><A HREF="#filter">Filter</A> 
                 <LI><A HREF="#mixins">Mixin Classes</A> 
-                <LI><A HREF="#callstack_info">Callstack Information</A> 
                 <LI><A HREF="#precedence order">Precedence Order</A>
 	        <LI><A HREF="#guards">Guards for Filters and Mixins</A>
                 <LI><A HREF="#updateinterceptors">Querying, Setting, Altering Filter and Mixin Lists</A>
+	        <LI><A HREF="#callstack_info">Querying Call-stack Information</A> 
         </UL>
       </P>
-
-      <LI><A HREF="#forwarding">Method Forwarding</A> 
-      <LI><A HREF="#nesting">Nested Classes and Dynamic Object Aggregations</A> 
-
-	<LI><A HREF="#assertions">Assertions</A>
+      <LI><A HREF="#slots">Slots</A>
+	<UL>
+	  <LI><A HREF="#system-slots">System Slots</A>
+	  <LI><A HREF="#attribute-slots">Attribute Slots</A>
+          <LI><A HREF="#setter">Setter and Getter Methods for Slots</A>
+          <LI><A HREF="#parameter">Backward-compatible Short-Hand Notation
+          for Attribute Slots</A>
+          <LI><A HREF="#slot-experimental">Experimental Slot Features</A>
+          <UL>
+            <LI><A HREF="#value-checking">Value Checking</A>
+            <LI><A HREF="#trace-commands">Init Commands and Value Commands for Slot Values</A>
+          </UL>
+	</UL>
+	<P>
+    
+        <LI><A HREF="#nesting">Nested Classes and Dynamic Object Aggregations</A>
+        <UL>
+          <LI><A href="#nested-classes">Nested Classes</A>
+          <LI><A href="#obj-agg">Dynamic Object Aggregations</A>
+          <LI><A href="#nest-agg">Relationship between Class Nesting
+          and Object Aggregation </A>
+          <LI><A href="#contains">Simplified Syntax for Creating
+          Nested Object Structures</A>
+          <LI><A href="#copy-move">Copy/Move</A>
+        </UL>
+        <p>
+        
+        <LI><A HREF="#forwarding">Method Forwarding</A>
+        
+        <LI><A HREF="#assertions">Assertions</A>
 	<LI><P STYLE="margin-bottom: 0in">
-	  <A HREF="#additional-functionalities">AdditionalFunctionalities</A> 
+	  <A HREF="#additional-functionalities">Additional Functionalities</A> 
 	<UL>
 		<LI><A HREF="#abstract-classes">Abstract Classes</A> 
-		<LI><A HREF="#parameter">Parameter</A> 
                 <LI><A HREF="#autonames">Automatic Name Creation</A> 
                 <LI><A HREF="#meta-data">Meta-Data</A>
 	</UL>
@@ -158,11 +182,11 @@
 does not require OTcl to compile.</P>
 
 <P>XOTcl runs in the <tt>tclsh</tt> and provides a few extension
-commands. These are offered in a Tcl namespace ::xotcl, and need to be
-imported into the current namespace. All Tcl-commands
-remain available (and are also applicable on the extension
-constructs).
-</P>
+commands. These are offered in a Tcl namespace <tt>::xotcl</tt>, and
+can be imported into the current namespace to reduce typing and
+improve readability. All Tcl commands remain available (and are also
+applicable on the extension constructs).  </P>
+
 <P>A central property of Tcl is, that it uses strings solely for the
 representation of data. Internally it uses an dynamic type system with
 automatic conversion (which enables efficient type handling).  For
@@ -214,6 +238,12 @@
 	interface and the reliability problems caused by dynamic typing and,
 	therefore, to ease the combination of components. 
 	</P>
+	<LI><P STYLE="margin-bottom: 0in"><I>Forwarders</I>, to delegate
+          calls efficiently to other objects or classes.
+	</P>
+  	<LI><P STYLE="margin-bottom: 0in"><I>Slots</I>, to manage values
+          of instance variables with a common interface.
+	</P> 
 	<LI><P><I>Meta-data and Automatic Documentation</I>, to enhance self-documentation of objects
 	and classes. 
 	</P>
@@ -692,13 +722,20 @@
   kitchen <tt>destroy</tt>
 </pre><P>
 To invoke a user-defined destruction process, it is possible to
-overload this instance method in every class derived from object. 
+overload this instance method in every class derived from object.
 </P>
+<P>
+Note that the destruction of an object is performed by the
+method <tt>destroy</tt> of Object (since every object is an instance
+of <tt>Object</tt>, every object can call <tt>destroy</tt>). When an application class
+overloads <tt>destroy</tt>, this method should contain a <tt>next</tt> in order
+to reach the base class and to actually destroy the object. 
+</P>
 <H3><A NAME="data_on_obj"></A>Data on Objects 
 </H3>
 <P>The <tt>Object</tt> class provides a range of operations to manage
 objects, including those to manipulate data-structures on the
-objects. They are similiar to the same-named Tcl-commands: 
+objects. They are similar to the same-named Tcl-commands: 
 </P>
 <pre CLASS="code">
   <em>objName</em> <tt>set</tt> <em>varname ?value?</em>
@@ -742,10 +779,10 @@
 object-oriented call to an object of the form 
 </P>
 <pre CLASS="code">
-  <em>objName</em> <tt>array</tt> <em>option ary args</em>
+  <em>objName</em> <tt>array</tt> <em>option arrayName args</em>
 </pre><P>
 forwards its arguments to an <tt>array</tt> Tcl-command for the
-object&acute;s instance variable <tt>ary</tt>. It could be used like
+object&acute;s instance variable <tt>arrayName</tt>. It could be used like
 the same-named Tcl-command, e.g. the command 
 </P>
 <pre CLASS="code">
@@ -1077,7 +1114,7 @@
 </pre><P>
 A special instproc, the constructor <tt>init</tt>, was mentioned
 already. Now we are able to define such an instproc. Defined on a
-class it is responsible for all initialisation tasks, which needed to
+class it is responsible for all initialization tasks, which needed to
 be performed, when constructing a new instance object of the class.
 The constructor of the <tt>Room</tt> can initialize a variable for
 the color, in which the ceiling is painted, to white as default,
@@ -1213,17 +1250,17 @@
 Note the transition the kitchen was going through: firstly it was a
 singular object, then it was an object with a user-defined class,
 and now it is a class. This is possible (and not senseless) because
-of the per-object specialisation ability and the dual shape of a
+of the per-object specialization ability and the dual shape of a
 class, which is at the same time object and class. Both lead to a
 seamless connection of the run-time properties (the object features)
 and their descriptive properties (the class features). It is possible
 to avoid the strict distinction between them, known from static typed
 languages, like C++, Java, etc. 
 </p>
 <p>Moreover, since the syntaxes of constructs expressing the same
-concern are nearly identical, we can refactor a solution with very few 
+concern are nearly identical, we can re-factor a solution with very few 
 changes to the alternative. We will see similar "ease of refactoring"
-throughout the XOTcl language. E.g., we can also easily refactor the
+throughout the XOTcl language. E.g., we can also easily re-factor the
 class hierarchies or exchange class hierarchies against mixin
 solutions with only slight changes in the code.
 </P>
@@ -1293,7 +1330,9 @@
 hierarchy, the class <tt>Object</tt>, is searched. 
 </P>
 
-<P>The usage of <tt>next</tt> in XOTcl is different to OTcl: In OTcl
+<P>The usage of <tt>next</tt> in XOTcl is different to OTcl: In OTcl,
+	 <tt>next</tt> is defined as a method, in XOTcl it is a
+	primitive command. Furthermore, in OTcl, 
 it is always necessary to provide the full argument list for every
 invocation explicitly. In XOTcl, a call of <tt>next</tt> without
 arguments can be used to call the shadowed methods with the same
@@ -1331,19 +1370,17 @@
 the next shadowed method on the next path is searched and, when it is
 found, it is mixed into the execution of the current method. When no
 method is found, the call of <tt>next</tt> returns an empty string,
-otherwise it returns the result of the called method. Note, that the
-realization through a primitive command -- similar to the <tt>self</tt>
-command -- is a difference to OTcl, where <tt>next</tt> is realized
-through an instance method of <tt>Object</tt>. The syntax is: 
+otherwise it returns the result of the called method. 
+The syntax is: 
 </P>
 <pre CLASS="code">
   <tt>next</tt> <em>?arguments|--noArgs?</em>
 </pre><P>
-Note, that also the usage of <tt>next</tt> in XOTcl is different to
+As stated earlier the usage of <tt>next</tt> in XOTcl differs from
 OTcl, since the <tt>next</tt> call without arguments in OTcl means
 per default that no arguments are passed. But most often all
-arguments are passed through to the shadowed method (since it will
-most likely have the same signature like its predecessor). When all
+arguments are passed through to the shadowed methods (since these will
+most likely have the same signatures). When all
 variables should be passed through, in OTcl it is necessary for
 correct variable substitution to use: 
 </P>
@@ -1414,7 +1451,7 @@
 </P>
 <p>By the way, an observant reader might notice that the example
 above can be rewritten without explicit constructors, just by
-using paramters with default values.
+using parameters with default values.
 </p>
 <pre CLASS="code">
   <tt>Class</tt> Room <tt>-parameter</tt> {{roomNumber 0}}
@@ -1629,7 +1666,7 @@
   <tt>Class</tt> NoClassInfo <tt>-superclass</tt> <tt>Class</tt>
   <it># redefine info ability</it>
   NoClassInfo <tt>instproc</tt> <tt>info</tt> args {
-    error &quot;No class info avaiable&quot;
+    error &quot;No class info available&quot;
   }
   <it># derive agent class from meta-class, which</it>
   <it># can not access class info</it>
@@ -1806,11 +1843,11 @@
 </pre>
 
 <H2>
-<A NAME="non-pos-args"></A>Non-positional Arguments
+<A NAME="non-pos-args"></A>Methods with Non-Positional Arguments
 </H2>
 <P>
 <P>
-So far we have introduces methods only with positional arguments: that
+So far we have introduced methods only with positional arguments: that
 is, the position of an argument in the argument list determines to
 which local variable the argument is bound, when the method is
 invoked. Sometimes non-positional arguments -- arguments that carry
@@ -1910,7 +1947,7 @@
 A check option method has the following syntax:
 </P>
 <pre CLASS="code">
- <em>someobject|someclass</em> <tt>proc|instproc</tt> methodName {?optional nonpositional arguments? argName arg} {
+ <em>someobject|someclass</em> <tt>proc</tt>|<tt>instproc</tt> methodName {?optional nonpositional arguments? argName arg} {
   ...
  }
 </pre>
@@ -2740,8 +2777,259 @@
   ::X12 
   ::X
 </pre>
+<H2><A NAME="precedence order"></A>Precedence Order
+</H2>
+
+<P>The precedence order is composed by the precedence order of the
+superclass hierarchy (as explained earlier) and the message
+interceptors. In general, filters precede mixins and the superclass
+hierarchy. They are applied in the order of the next path of the
+object. Thus per-object filters are ordered before per-class
+filters.</p>
+
+<p>Mixins are processed after the filters. Again, they are applied in
+the order of the next path of the object. Thus per-object mixins are
+ordered before per-class mixins.</p>
+
+<p>Finally, the object's own heritage order comes in the order: object,
+class, superclasses.</p>
+
+<p>The three precedence order lists (filters, mixins, and classes) are
+pre-calculated and cached.</p>
+
+<p>Filters as well as classes (mixins and ordinary classes) are
+linearized. That means, each filter and each class can be only once on
+a precedence order list. If a filter or class can be reached more than
+once, than the last occurrence is used.</p>
+
+<p>For instance, consider a class A is superclass, per-class mixin,
+and per-object mixin. On the precedence order lists only the last
+occurrence as a superclass is used after linearization.</P>
+
+
+<H2><A NAME="guards"></A>Guards for Filters and Mixins
+</H2>
+
+Message interceptors, such as filters and mixins, are applied for
+potentially huge number of messages. In many cases it is possible to
+reduce the effective number of cases in which interceptors are
+applied. Interceptor guards offer this functionality: they are boolean
+conditions with which you can specify in which cases a registered
+interceptor should be applied.
+
+<H3><A NAME="filter_guards"></A> Filter Guards</H3>
+<P>
+A filter guard is a set of conditions that determine whether a filter
+is to be executed upon a certain invocation or not. Syntactically we can
+append a filter guard to the filter registration, or it can be
+registered using the methods <tt>filterguard</tt> for filters and
+<tt>instfilterguard</tt> for instfilters.
+
+</P><P> Each filter guard is an ordinary condition. A filter guard is
+executed in the call frame of the filter to be executed, if the filter
+guard returns 1. Thus, the call-stack information are already set to
+the values of the targeted filter - and these values can be used in
+the filter guard.
+
+</P><P>
+Let us consider a simple program:
+</P>
+<pre CLASS="code">
+<tt>Class</tt> Room
+Room <tt>instproc</tt> enter {name} {<tt>puts</tt> [<tt>self proc</tt>]}
+Room <tt>instproc</tt> leave {name} {<tt>puts</tt> [<tt>self proc</tt>]}
+Room <tt>instproc</tt> loggingFilter args {
+    <tt>puts</tt> [<tt>self calledproc</tt>]
+    <tt>next</tt>
+}
+Room <tt>instfilter</tt> loggingFilter
+</pre>
+
+<P>
+Now consider we only want to apply the logging filter for enter and
+leave, not for any other message sent to Room instances. In the
+following example, for instance, we do not want to log the <tt>set</tt>
+message:
+</p>
+
+<pre CLASS="code">
+Room r 
+r enter Uwe
+r leave Uwe
+r <tt>set</tt> roomName "Office"
+</pre>
+
+<P>
+In this example a filterguard can be applied to restrict the
+application of the filter to those two methods:
+</p>
+
+<pre CLASS="code">
+Room <tt>instfilterguard</tt> loggingFilter {
+  <tt>[self calledproc</tt>] == "enter" || 
+  [<tt>self calledproc</tt>] == "leave"}
+</pre>
+
+<P>
+Here we limit the filter application of the logging filter on rooms to
+calls to enter and leave. All other calls are not filtered at
+all. Note that the same syntax can also be applied for
+<tt>filterguard</tt>. Also, there is a short form to register filter
+guards directly during filter registration. The following code has the
+same semantics as the filter and filter guard definitions above:
+</P>
+
+<pre CLASS="code">
+Room <tt>instfilter</tt> {{loggingFilter <tt>-guard</tt> {
+    [<tt>self calledproc</tt>] == "enter" || 
+    [<tt>self calledproc</tt>] == "leave"}}}
+</pre><P>
+
+The filter guard language construct is registration centric. It only
+applies for the class or object on which a filter is registered, not
+for all applications of the filter method. That is, if we use
+loggingFilter on another class we may give no or completely
+different filter guards.
+</P><P>
+If no filter guard is given for a filter, we assume that it is to be
+applied on all methods (equivalent to the filter guard '1' which is
+always true).
+</P>
+
+<P>
+There are introspection options for filter guards. In particular, we
+can use <tt>info filterguard</tt> and <tt>info instfilterguard</tt>
+for getting the filter guards for a particular filter or instfilter
+respectively. For instance:
+</P>
+<pre CLASS="code">
+<tt>puts</tt> [Room <tt>info instfilterguard </tt>loggingFilter]
+</pre><P>
+This prints out the content of the above guard definition. 
+We can also append <tt>-guard</tt> to <tt>info filter</tt> or 
+<tt>info instfilter</tt> to obtain a filter definition with guards:
+</P>
+<pre CLASS="code">
+<tt>puts</tt> [Room <tt>info instfilter -guards</tt>]
+</pre><P>
+
+<P>
+If we call a method from within a filter guard, as for instance
+callsMethod, we might require some parameters from the guard's
+context, such as <tt>calledproc</tt>. These parameters can be passed
+as references, as in the following example:
+</P>
+
+<pre CLASS="code">
+  Room <tt>instfilter</tt> loggingFilter
+  Room <tt>instfilterguard</tt> loggingFilter {[<tt>my</tt> callsMethod openURL [<tt>self calledproc</tt>]]}
+</pre><P>
+This example works because the filterguard is already set to the scope of the guard. Now we can use this dynamic  <tt>calledproc</tt> context in the called method:
+</P>
+<pre CLASS="code">
+  Room <tt>instproc</tt> callsMethod {method calledproc} {
+    <tt>return</tt>[<tt>string</tt> <tt>match</tt> $calledproc $method]
+  }
+</pre><P>
+We simply check whether the called method
+matches the given method name or not.
+
+<H3><A NAME="mixin_guards"></A> Mixin Guards</H3>
+<P>
+Similar to filters, there are mixin guards, defined with
+<tt>mixinguard</tt> and <tt>instmixinguard</tt>, or with
+<tt>-guard</tt> during mixin registration. Consider a simple example:
+there are a number of birds who have two mixins: Fly and Sing. For Fly
+there are limitations: a bird can only fly if it is at least two years
+old and is not a Penguin. Such problems are  be solved with
+mixin guards:
+</P>
+
+<pre CLASS="code">
+  <tt>Class</tt> Fly
+  Fly <tt>instproc</tt> fly {} {<tt>puts</tt> "[<tt>my</tt> signature]: yippee, fly like an eagle!"}
+
+  <tt>Class</tt> Sing
+  Sing <tt>instproc</tt> sing {} {<tt>puts</tt> "[<tt>my</tt> signature]: what a difference a day makes"}
+
+  <tt>Class</tt> Animal -parameter age
+  Animal <tt>instproc</tt> unknown args { <tt>puts</tt> "[<tt>my</tt> signature]: how should I $args?"}
+  Animal <tt>instproc</tt> signature {} {
+    <tt>return</tt> "[<tt>self</tt>] [<tt>my info class</tt>] ([<tt>my</tt> age] years)"
+  }
+
+  <tt>Class</tt> Bird -superclass Animal
+  <tt>Class</tt> Penguine -superclass Bird
+  <tt>Class</tt> Parrot -superclass Bird
+  <tt>Class</tt> Duck -superclass Bird
+
+  Parrot tweedy -age 1
+  Penguine pingo -age 5
+  Duck donald -age 4
+  Parrot lora -age 6
+
+  Bird <tt>instmixin</tt> {{Fly <tt>-guard</tt> {[my age] > 2 && ![<tt>my istype</tt> Penguine]}} Sing}
+</pre><P>
+An invocation like:
+</P>
+
+<pre CLASS="code">
+<tt>foreach</tt> bird {tweedy pingo donald lora} { $bird fly }
+</pre><P>
+yields the following result:
+</P>
+<pre CLASS="code">
+::tweedy ::Parrot (1 years): how should I fly?
+::pingo ::Penguine (5 years): how should I fly?
+::donald ::Duck (4 years): yippee, fly like an eagle!
+::lora ::Parrot (6 years): yippee, fly like an eagle!
+</pre>
+
+<P>
+There are similar introspection options for mixin guards as those for
+filter guards. In particular, we can use <tt>info mixinguard</tt> and
+<tt>info instmixinguard</tt> for getting the mixin guards for a
+particular mixin or instmixin respectively.
+</P>
+
+<H2><A NAME="updateinterceptors"></A>Querying, Setting, Altering Filter and Mixin Lists
+</H2>
+
+The methods <tt>mixin</tt>, <tt>instmixin</tt>, <tt>filter</tt> and
+<tt>instfilter</tt> are <a href='#system-slots'>system slots</a>
+having the same query and update interface. 
+<UL>
+<LI>If one of those methods is called without argument, it returns the current
+setting. </LI>
+<LI>If it is called with one argument, the argument is used to
+set the specified list as indicated in the above examples. </LI>
+<LI>If these methods are called with more than one argument, the first argument
+is used to specify the action. Possible values for the action are
+<tt>set</tt>, <tt>get</tt>, <tt>add</tt> and <tt>delete</tt>. See below for 
+commonly used examples. 
+</UL>
+<P>
+<CENTER>	
+<TABLE BORDER='1' width='90%'>
+<TR><TD nowrap='1'><tt>obj mixin</tt></TD>            <TD>same as: <tt>obj info mixin</tt></TD></TR>
+<TR><TD nowrap='1'><tt>obj mixin {C1 C2}</tt></TD>    <TD>same as: <tt>obj mixin assign {C1 C2}</tt></TD></TR>
+<TR><TD nowrap='1'><tt>obj mixin assign {C1 C2}</tt></TD><TD>sets the mixins for <tt>obj</tt></TD></TR>
+<TR><TD nowrap='1'><tt>obj mixin add C3</tt></TD>     <TD>adds the mixin <tt>C3</tt> on front of the mixin list</TD></TR>
+<TR><TD nowrap='1'><tt>obj mixin add C3 end</tt></TD> <TD>adds the mixin <tt>C3</tt> at the end the mixin list</TD></TR>
+<TR><TD nowrap='1'><tt>obj mixin add C3 3</tt></TD>   <TD>adds the mixin <tt>C3</tt> at the 3rd position</TD></TR>
+<TR><TD nowrap='1'><tt>obj mixin delete ::C3</tt></TD><TD>removes the mixin <tt>C3</tt> from the mixin list.
+Use absolute class names. <tt>delete</tt> supports an optional flag <tt>-nocomplain</tt> that does not produce an error, when the specified class is not in the list. 
+</TD></TR>
+</TABLE>
+</CENTER>	
+</P>
+<P>
+Note, that the list of possible actions can be 
+extended by extending the class <tt>::xotcl::Relations</tt>.
+</P>
+
 <H2>
-<A NAME="callstack_info"></A>Callstack Information
+<A NAME="callstack_info"></A>Querying Call-stack Information
 </H2>
 <P STYLE="margin-bottom: 0in">Since the presented interceptors are
 normal XOTcl instprocs they can access all XOTcl introspection
@@ -2778,7 +3066,7 @@
 	      If the current command was invoked from
 	    an XOTcl method the absolute level is returned (e.g. #4)
 	    which can be used in the <tt>uplevel</tt> or
-	    <tt>upvar</tt> tcl command or XOTcl method. If the current
+	    <tt>upvar</tt> Tcl command or XOTcl method. If the current
 	    command was not invoked from an XOTcl method, the value 1
 	    is returned.
 	  </TD>
@@ -2821,7 +3109,7 @@
 	    computation. If the current command was invoked from an
 	    XOTcl method the absolute level is returned (e.g. #4)
 	    which can be used in the <tt>uplevel</tt> or
-	    <tt>upvar</tt> tcl command or XOTcl method. If the current
+	    <tt>upvar</tt> Tcl command or XOTcl method. If the current
 	    command was not invoked from an XOTcl method, the value 1 is
 	    returned.
 	  </TD>
@@ -2946,257 +3234,587 @@
 are #1.
 </P>
 
-<H2><A NAME="precedence order"></A>Precedence Order
-</H2>
+<!-- PAGE BREAK -->
 
-<P>The precedence order is composed by the precedence order of the
-superclass hierarchy (as explained earlier) and the message
-interceptors. In general, filters precede mixins and the superclass
-hierarchy. They are applied in the order of the next path of the
-object. Thus per-object filters are ordered before per-class
-filters.</p>
+<TABLE COLS=2 WIDTH=100% BORDER=0 CELLPADDING=2 CELLSPACING=0 BGCOLOR="#000055">
+    <TR>
+      <TD WIDTH=75%>
+	<P><A NAME="slots"></A><FONT COLOR="#ffffff" FACE="Arial, Helvetica" SIZE=6>Slots</FONT>
+	</P>
+      </TD>
+      <TD>
+	<IMG SRC="logo-100.jpg" NAME="Graphic9" ALIGN=RIGHT WIDTH=102 HEIGHT=42 BORDER=0></TD>
+    </TR>
+</TABLE>
 
-<p>Mixins are processed after the filters. Again, they are applied in
-the order of the next path of the object. Thus per-object mixins are
-ordered before per-class mixins.</p>
+<p>A slot is a meta-object that manages property-changes of objects. A
+property is either an attribute or a role in an relation.  In a
+nutshell, a slot has among other attributes:</p>
 
-<p>Finally, the object's own heritage order comes in the order: object,
-class, superclasses.</p>
+<ul>
+<li>a <em>name</em> (which it used to access it), 
+<li>a <em>domain</em> (object or class on which it can be used) , and
+<li>can be <em>multivalued</em> or not.
+</ul>
 
-<p>The three precedence order lists (filters, mixins, and classes) are
-pre-calculated and cached.</p>
+<p> We distinguish between <em>system slots</em> (predefined slots
+  like <tt>class</tt>, <tt>superclass</tt>, <tt>mixin</tt>,
+  <tt>instmixin</tt>, <tt>filter</tt>, <tt>instfilter</tt>) and
+  <em>attribute slots</em> (e.g. attributes of classes).  </p>
 
-<p>Filters as well as classes (mixins and ordinary classes) are
-linearized. That means, each filter and each class can be only once on
-a precedence order list. If a filter or class can be reached more than
-once, than the last occurrence is used.</p>
+<h2><a name='system-slots'></a>System Slots</h2>
+<p>
+System slots are predefined slots defining e.g. some relations
+between classes, or between objects and classes. The predefined system slots
+are:
+<ul>
+  
+  <li> <tt>superclass</tt>: every class in XOTcl has one or more
+  superclasses.  The name of this slot is <tt>superclass</tt>, the
+  domain is <tt>::xotcl::Class</tt>, the slot is multivalued, since
+  one object might have multiple superclasses.<p>
 
-<p>For instance, consider a class A is superclass, per-class mixin,
-and per-object mixin. On the precedence order lists only the last
-occurrence as a superclass is used after linearization.</P>
+  <li> <tt>class</tt>: every object has a class; therefore, the domain
+  of the slot is <tt>::xotcl::Class</tt>, the property is not multivalued.<p>
 
+  <li> <tt>mixin</tt>: every object in XOTcl can have one or more
+  mixin classes.  The name of this slot is <tt>mixin</tt>, the domain
+  is <tt>::xotcl::Object</tt> , the slot is multivalued.<p>
 
-<H2><A NAME="guards"></A>Guards for Filters and Mixins
-</H2>
+  <li> <tt>instmixin</tt>: same as above, but the domain is
+  <tt>::xotcl::Class</tt>.<p>
 
-Message interceptors, such as filters and mixins, are applied for
-potentially huge number of messages. In many cases it is possible to
-reduce the effective number of cases in which interceptors are
-applied. Interceptor guards offer this functionality: they are boolean
-conditions with which you can specify in which cases a registered
-interceptor should be applied.
+  <li> <tt>filter</tt>, <tt>instfilter</tt>: similar to <tt>mixin</tt>
+  and <tt>instmixin</tt>.
 
-<H3><A NAME="filter_guards"></A> Filter Guards</H3>
-<P>
-A filter guard is a set of conditions that determine whether a filter
-is to be executed upon a certain invocation or not. Syntactically we can
-append a filter guard to the filter registration, or it can be
-registered using the methods <tt>filterguard</tt> for filters and
-<tt>instfilterguard</tt> for instfilters.
+</ul> <p>The system slots were introduced earlier with their
+semantics.  Here we just point out, that they have all the same
+interfaces for querying, setting, adding and removing of slot
+values.</p>
 
-</P><P> Each filter guard is an ordinary condition. A filter guard is
-executed in the call frame of the filter to be executed, if the filter
-guard returns 1. Thus, the callstack information are already set to
-the values of the targeted filter - and these values can be used in
-the filter guard.
+<p>Every slot can be used set and query the property from its domain.
+The syntax for setting values is
+<pre CLASS="code">
+  <em>object property newValue</em>
+</pre>
+	 and for getting its values is
+<pre CLASS="code">
+   <tt>set</tt> x [<em>object property</em>]
+</pre>
+where <em>property</em> denotes the slot name.
+Every multivalued slot provides the methods <tt>add</tt> and
+<tt>delete</tt>.
 
-</P><P>
-Let us consider a simple program:
-</P>
+Here are a few examples for using the system slot <tt>mixin</tt> which we have introduced already in the section of the <a href='#mixins'>mixins</a>
 <pre CLASS="code">
-Class Room
-Room instproc enter {name} {puts [self proc]}
-Room instproc leave {name} {puts [self proc]}
-Room instproc loggingFilter args {
-    puts [self calledproc]
-    next
-}
-Room instfilter loggingFilter
+  <tt>Object</tt> o; <tt>Class</tt> M; <tt>Class</tt> N
+  o <tt>mixin</tt> ::M      <em>;# replacing the per-object mixins of o with M</em>
+  o <tt>mixin reset</tt> ::M  <em>;# same as before</em>
+  o <tt>mixin add</tt> ::N   <em>;# add N to the front of the mixin list</em>
+  o <tt>mixin delete</tt> ::M <em>;# delete M from the mixin list</em>
+  puts [o <tt>mixin</tt>]   <em>;# query the current mixin list</em>
+</pre>         
+
+Every system slot (e.g. superclass) has the exact same interface.
+
+<h2><a name='attribute-slots'></a>Attribute Slots</h2>
+
+<p> Attribute slots are used to manage the setting and querying of
+instance variables. We define now a person with three attributes
+<tt>name</tt>, <tt>salary</tt> and <tt>projects</tt>. </p>
+
+<pre CLASS="code">
+  <tt>Class</tt> Person <tt>-slots</tt> {
+    <tt>Attribute</tt> name
+    <tt>Attribute</tt> salary <tt>-default</tt> 0
+    <tt>Attribute</tt> projects <tt>-default</tt> {} <tt>-multivalued</tt> true
+  }
 </pre>
 
-<P>
-Now consider we only want to apply the logging filter for enter and
-leave, not for any other message sent to Room instances. In the
-following example, for instance, we do not want to log the <tt>set</tt>
-message:
+<p>These attributes might have a default value or they might be 
+      multivalued. When an instance of class Person is created, the
+      slot names can be used for specifying values for the slots.</p>
+
+<pre CLASS="code">
+  Person p1 -name "Joe"	
+</pre>
+
+<p>Object p1 has three instance variables, namely <tt>name</tt>,
+<tt>salary</tt> and <tt>projects</tt>. Since slot <tt>projects</tt> is
+multivalued, we can add a value to the list of values the <tt>add</tt>
+subcommand.</p>
+
+<pre CLASS="code">
+  Project project1 -name XOTcl \
+     -description "A highly flexible OO scripting language"
+
+  p1 projects <tt>add</tt> ::project1
+  p1 projects <tt>add</tt> some-other-value
+</pre>
+
+<p>The value of the instance variable <tt>project</tt> of Person
+<tt>p1</tt> is now the list <tt>{some-other-value ::project1}</tt>.
 </p>
 
+<p>Attribute slots are implemented via dynamic object aggregations
+(see <a href='#nesting'>below</a>), where the Class objects contain
+the slot objects with the information like default etc. In order to
+prevent name clashes between the slot objects and the methods of a
+class (like e.g. <tt>create</tt>), an intermediary object named
+<tt>slot</tt> is used as a container of the slot objects. In the example above
+we create an object structure of the following form:</p>
 <pre CLASS="code">
-Room r 
-r enter Uwe
-r leave Uwe
-r set roomName "Office"
+  Person
+  Person <tt>slot</tt> name
+  Person <tt>slot</tt> salary
+  Person <tt>slot</tt> projects
 </pre>
 
-<P>
-In this example a filterguard can be applied to restrict the
-application of the filter to those two methods:
+<p> This object structure can be used to to query and modify the slot
+properties or to add additional methods to the slot objects. One
+application is for example to used slot-specific methods for checking
+slot values, as shown in the next section. The slot objects are
+ordinary XOTcl objects with their own slots
+(such as <tt>default</tt>, <tt>name</tt> etc.). The following example
+set and queries the default of the slot <tt>name</tt> of <tt>Person</tt>:
 </p>
 
 <pre CLASS="code">
-Room instfilterguard loggingFilter {
-  [self calledproc] == "enter" || 
-  [self calledproc] == "leave"}
+  Person <tt>slot</tt> name <tt>default</tt> "gustaf"
+  ? {Person <tt>slot</tt> name <tt>default</tt>} gustaf
 </pre>
 
+<p>However, due to the current implementation, it is necessary to
+re-init the slot object when the slot properties (such as
+e.g. <tt>default</tt>) are changed. This can be achieved by calling
+the method <tt>init</tt> of the slot object.
+</p>
+
+<H3><A NAME="setter"></A>Setter and Getter Methods for Slots</H3>
+
+<p>When a slot is called via its name, the call is delegated to the
+slot object. Per default, the slot value is read via the <tt>get</tt>
+method of the slot and it is set the <tt>assign</tt> method. By
+redefining these methods, it is possible to provide custom setter and
+getter methods. The following example redefines the setter methods
+<tt>assign</tt> to check, whether an attribute value is within the
+range between 1 and 99.</p>
+
+<pre CLASS="code">
+  Class <tt>create</tt> A <tt>-slots</tt> {
+    Attribute foo <tt>-default</tt> 1 <tt>-proc</tt> assign {domain var value} {
+      <tt>if</tt> {$value < 0 || $value > 99} {
+        <tt>error</tt> "$value is not in the range of 0 .. 99"
+      }  
+      $domain <tt>set</tt> $var $value
+    }
+  }
+
+  A <tt>create</tt> a1
+  ? {a1 foo 10} 10
+  ? {a1 foo} 10
+  ? {catch {a1 foo -1}} 1
+</pre>
+
+<p>For the most common simple cases with single valued attributes,
+where neither setter or getter are redefined, XOTcl optimizes the slot
+access function and replaces the delegation to the slot object by the
+the C-level implementation of <tt>instparametercmd</tt>.
+
+<p>Note that it is possible to subclass <tt>Attribute</tt> (e.g. in
+order to store more properties for attributes, like when attributes
+are stored in a relational database) or to register mixin-classes or
+filters.</p>
+
+<H3><A NAME="parameter"></A>Backward-compatible Short-Hand Notation
+for Attribute Slots</H3>
+
+<p>XOTcl provides a short-hand notation for creating attribute slots,
+which is backward compatible for the most important options of XOTcl
+verison prior to 1.5.0. Instead of writing</p>
+
+<pre CLASS="code">
+  <tt>Class</tt> Car <tt>-slots</tt> {
+    Attribute owner
+    Attribute doors -default 4
+  }
+</pre>
+<p>one can use as well </p>
+<pre CLASS="code">
+  <tt>Class</tt> Car <tt>-parameter</tt> {
+    owner
+    {doors 4}
+  }
+</pre>
+<p>The various features of the prior implementation of <tt>parameter</tt> are
+deprecated and will be removed in future versions.
 <P>
-Here we limit the filter application of the logging filter on rooms to
-calls to enter and leave. All other calls are not filtered at
-all. Note that the same syntax can also be applied for
-<tt>filterguard</tt>. Also, there is a short form to register filter
-guards directly during filter registration. The following code has the
-same semantics as the filter and filter guard definitions above:
-</P>
 
+<h2><a name='slot-experimental'></a>Experimental Slot Features</h2>
+<h3><a name='value-checking'></a>Value Checking</h3>
+
+<p>Attribute slots can have types assigned which are tested whenever
+the instance variable is altered.  The slot <tt>salary</tt> is defined
+as integer whereas <tt>projects</tt> is defined to be a list of
+instances of the class <tt>::Project</tt> (a list of instances, since
+<tt>projects</tt> is defined as multivalued).  </p>
+
 <pre CLASS="code">
-Room instfilter {{loggingFilter -guard {
-    [self calledproc] == "enter" || 
-    [self calledproc] == "leave"}}}
-</pre><P>
+  <tt>Class</tt> Person <tt>-slots</tt> {
+    <tt>Attribute</tt> name
+    <tt>Attribute</tt> salary <tt>-default</tt> 0 <tt>-type</tt> integer
+    <tt>Attribute</tt> projects <tt>-default</tt> {} <tt>-multivalued</tt> true <tt>-type</tt> ::Project
+    <em>...</em>
+  }
 
-The filter guard language construct is registration centric. It only
-applies for the class or object on which a filter is registered, not
-for all applications of the filter method. That is, if we use
-loggingFilter on another class we may give no or completely
-different filter guards.
-</P><P>
-If no filter guard is given for a filter, we assume that it is to be
-applied on all methods (equivalent to the filter guard '1' which is
-always true).
+  Person p2 -name "Sue"	-salary 1000
+</pre>
+
+<p>It is as well possible to define custom value checkers and to
+normalize the input values.  We extend the previous example and define
+"<tt>my sex</tt>" as value for <tt>type</tt>.  If the value checker
+consists of multiple words, the type check compiler assumes that the
+value is a Tcl command, to which the actual value is appended as
+additional argument before invocation. <tt>my</tt> refers to the 
+slot object. In the example below, we define for the slot object an
+object specific method that returns 1 or 0 depending on the success of the
+check. This method (a) checks the values via <tt>switch</tt>
+and (b) normalizes and resets the value via <tt>uplevel</tt>. 
+</p>
+
+<pre CLASS="code">
+  <tt>Class</tt> Person <tt>-slots</tt> {
+    <em>...</em>
+    <tt>Attribute</tt> sex <tt>-type</tt> "my sex" <tt>-proc</tt> sex {value} {
+      <tt>switch -glob</tt> $value {
+        m* {<tt>my uplevel</tt> {$obj <tt>set</tt> $var m}; <tt>return</tt> 1}
+        f* {<tt>my uplevel</tt> {$obj <tt>set</tt> $var f}; <tt>return</tt> 1}
+        <tt>default</tt> {<tt>return</tt> 0}
+      }
+    }
+  }
+</pre>
+
+
+<p>The slot values are actually checked via Tcl variable traces whenever the
+associated variable gets a new value assigned. This means that the values are
+enforced now matter how the variables are set. Therefore, the
+checks are performed in the following two commands as well, although
+the slot values are not accessed via the slot names. The checks will
+throw an error in the second command, since <tt>1100x</tt> is not an
+integer.  </p>
+
+<pre CLASS="code">
+  p2 <tt>incr</tt> salary 100
+  p2 <tt>append</tt> salary x
+</pre>     
+
+<p> Similarly the second command below will throw an error, since
+<tt>some-other-value</tt> is not an instance of <tt>::Project</tt>.
+
+<pre CLASS="code">
+  p2 projects <tt>add</tt> ::project1
+  p2 projects <tt>add</tt> some-other-value     
+</pre>
+
+<p> When a check throws an error, the instance variables 
+     are reset to the previous value. To restore the original
+     value, an associative array <tt>__oldvalue()</tt> is kept as 
+     instance variable in the object.
+</p>
+
+<p>  In general, checking of variables can be turned off globally
+     by
+<pre CLASS="code">
+  ::xotcl::Slot <tt>instmixin add</tt> ::xotcl::Slot::Nocheck
+</pre>
+<p>
+     This mixin replaces the methods <tt>check</tt> and
+     <tt>checkall</tt> as well as <tt>mk_type_checker</tt> by
+     no-ops. When the mixin is active and the Attribute definitions
+     are loaded, the specified <tt>type</tt> has no effect.
+</p>
+<p>
+     Value checking can be turned off also selectively for each slot via
+     using <tt>::xotcl::Slot::Nocheck</tt> as per-object-mixin; if
+     attributes are subclassed, 
+     it is possible to register the <tt>Nocheck</tt> mixin on a
+     subclass of <tt>Attribute</tt>. 
+</p>
+
+<h3><a name='trace-commands'></a>Init Commands and Value Commands for Slot Values</h3>
+
+<p>An init command (<tt>initcmd</tt>) of a slot is similar to a
+default and is a command to be executed when the value of the
+associated variable is read the first time. That means that when an
+object is created the associated variable has no value. On the
+contrary, when a default is used, the variable is set to the default
+value, when the object is created. </p>
+
+The primary advantage of slot init commands is <em>Lacy
+initialization:</em> When an object has many slots and the
+initialization of all slots is costly (e.g. the value of each slot is
+fetched from a relational database), and not all of the values are
+needed for each instance, only the relevant variables of the object
+are initialized on demand.
+
+<pre CLASS="code">
+  Class C -slots {
+    Attribute x -initcmd {puts {init}; set _ 101}
+  }
+
+  C c1
+  c1 <tt>info</tt> vars  <it>;# ==&gt; returns ""</it>
+  c1 <tt>set </tt> x     <it>;# ==&gt; puts init, returns 101</it>
+  c1 <tt>info</tt> vars  <it>;# ==&gt; returns "x"</it>
+</p>
+</pre>
+
+<p>The initcmd is executed only once, when the variable is read the first
+time. For later reads of the variable contents, the values are returned.
+
+<p>A value command (<tt>valuecmd</tt>) of a slot is similar to a a
+init command, except that it is executed whenever the value of the
+variable is read. A value command can be used e.g. to implement live
+updates for variables or for abstracting from sql sequences or the
+like.  </p>
+
+<p>Finally the value changed command (<tt>valuechangedcmd</tt>) can be
+used to specify the behavior, whenever the value of the variable is
+altered. This option is used to implement the value checking described
+in the last section.</p>
+
+<p> The slot parameters <tt>default</tt>, <tt>initcmd</tt> and
+<tt>valuecmd</tt> have to be used mutually exclusively.
+</p>
+
+
+
+<!-- PAGE BREAK -->
+
+<TABLE COLS=2 WIDTH=100% BORDER=0 CELLPADDING=2 CELLSPACING=0 BGCOLOR="#000055">
+	<TR>
+		<TD WIDTH=75%>
+			<P><A NAME="nesting"></A><FONT COLOR="#ffffff"><FONT FACE="Arial, Helvetica"><FONT SIZE=6>Nested Classes
+			and Dynamic Object Aggregations </FONT></FONT></FONT>
+			</P>
+		</TD>
+		<TD>
+			<IMG SRC="logo-100.jpg" NAME="Graphic9" ALIGN=RIGHT WIDTH=102 HEIGHT=42 BORDER=0></TD>
+	</TR>
+</TABLE>
+<P>Most object-oriented analysis and design methods are based on the
+concepts of generalization and aggregation. Generalization is
+achieved through class hierarchies and inheritance, while static
+aggregation is provided through embedding. Since version 8.0 Tcl
+offers a namespace concept which can be used as a mechanism to
+provide dynamic aggregations. 
 </P>
+<P>A <EM>namespace</EM> provides an encapsulation of variable and
+procedure names in order to prevent unwanted name collisions with
+other system components. Each namespace has a unique identifier which
+becomes part of the fully qualified variable and procedure names.
+Namespaces are therefore already object-based in the terminology of
+Wegner. OTcl is object-oriented since it offers classes and class
+inheritance. Its objects are also namespaces, but an object is more
+than only a namespace. Therefore, two incompatible namespace concepts
+have existed in OTcl in parallel. 
+</P>
+<P>In XOTcl every object and every class is
+logically implemented as a separate Tcl namespace. The biggest benefit of this
+design decision aside from performance advantages is the ability to
+aggregate objects and nest classes. Contrary in OTcl every object has
+a global identifier. Through the introspection abilities of
+namespaces nested classes are also traceable at runtime and can be
+changed dynamically. In XOTcl objects are allowed to contain nested
+objects, which are dynamically changeable aggregates of the
+containing object. 
+</P>
 
-<P>
-There are introspection options for filter guards. In particular, we
-can use <tt>info filterguard</tt> and <tt>info instfilterguard</tt>
-for getting the filter guards for a particular filter or instfilter
-respectively. For instance:
+
+<H3><A NAME="nested-classes"></A>Nested Classes</H3>
+
+<P>The notation for nested classes follows the syntax of Tcl
+namespaces by using ``::'' as a delimiter. For example the
+description of a oval carpet and a desk can nest inside of the
+<tt>OvalOffice</tt> class: 
 </P>
 <pre CLASS="code">
-puts [Room info instfilterguard loggingFilter]
+  <tt>Class</tt> OvalOffice
+  <it># general carpet</it>
+  <tt>Class</tt> Carpet
+  <tt>Class</tt> OvalOffice::Desk
+  <it># special oval carpet - no name collision</it>
+  <tt>Class</tt> OvalOffice::Carpet <tt>-superclass</tt> ::Carpet
 </pre><P>
-This prints out the content of the above guard definition. 
-We can also append <tt>-guard</tt> to <tt>info filter</tt> or 
-<tt>info instfilter</tt> to obtain a filter definition with guards:
+Nested classes can be used exactly like ordinary classes, a user can
+sub-class it, derive instances, etc. The information about the
+nesting structure of classes is available through the <tt>info</tt>
+instance method: 
 </P>
 <pre CLASS="code">
-puts [Room info instfilter -guards]
+  <em>className</em> <tt>info</tt> classchildren <em>?pattern?</em>
+  <em>className</em> <tt>info</tt> classparent
 </pre><P>
-
-<P>
-If we call a method from within a filter guard, as for instance
-callsMethod, we might require some parameters from the guard's
-context, such as <tt>calledproc</tt>. These parameters can be passed
-as references, as in the following example:
+The <tt>classchildren</tt> option returns a list of children, if one
+or more exist, otherwise it returns an empty string. <tt>classparent</tt>
+results in the name of the parent class, if the class is nested.
+Since nested classes are realized through namespaces, all
+functionality offered by Tcl's <tt>namespace</tt> command is usable
+from XOTcl as well. 
 </P>
+<H3><A NAME="obj-agg"></A>Dynamic Object Aggregations </H3>
 
+<P>The nested classes only provide an aggregation of the descriptive
+not of the runtime properties of an object. We have pointed out the
+difference of object and class in XOTcl. Because of the splitting of a
+class into class and class-object it is possible to give each object
+its own namespace. The internal implementation of objects enable them
+to contain nested objects, which are aggregates of the containing
+object. In XOTcl these can be changed dynamically and introspected
+through the language support of dynamic object aggregations <a
+href="#xotcl-aggregation">[Neumann and Zdun 2000b]</a>. Suppose an
+object of the class <tt>Agent</tt> should aggregate some property
+objects of an agent, such as head and body:
+</P>
 <pre CLASS="code">
-  Room <tt>instfilter</tt> loggingFilter
-  Room <tt>instfilterguard</tt> loggingFilter {[<tt>my</tt> callsMethod openURL [self calledproc]]}
+  <tt>Class</tt>Agent
+  Agent myAgent
+
+  <tt>Class</tt> Agent::Head
+  <tt>Class</tt> Agent::Body
+
+  Agent::Head ::myAgent::myHead
+  Agent::Body ::myAgent::myBody
 </pre><P>
-This example works because the filterguard is already set to the scope of the guard. Now we can use this dynamic  <tt>calledproc</tt> context in the called method:
+Now the objects <tt>myHead</tt> and <tt>myBody</tt> are part of the
+<tt>myAgent</tt> object and they are accessible through a
+qualification using ``::'' (or through Tcl's namespace command). But
+in the common case they will be accessed, as introduced so far: the
+explicit full qualification is not necessary when such variables are
+being accessed from within XOTcl methods, since the object changes to
+its namespace. 
 </P>
+<P>The information about the part-of relationship of objects can be
+obtained exactly the same way as for classes through the 
+<tt>info</tt> interface: 
+</P>
 <pre CLASS="code">
-  Room <tt>instproc</tt> callsMethod {method calledproc} {
-    <tt>return</tt>[<tt>string</tt> match $calledproc $method]
+  <em>objName</em> <tt>info</tt> children <em>?pattern?</em>
+  <em>objName</em> <tt>info</tt> parent
+</pre>
+
+<H3><A NAME="nest-agg"></A>Relationship between Class Nesting and Object Aggregation</H3>
+
+<P>The classes <tt>Head</tt> and <tt>Body</tt> are children of the
+<tt>Agent</tt> class. It is likely that all agents, interactive or
+not, have properties for head and body. This implies a static or
+predetermined relationship between class nesting and object
+aggregation. Such predetermination do not exist in XOTcl, but are
+simply build, when specifying the relationship in the constructor,
+e.g.: 
+</P>
+<pre CLASS="code">
+  Agent <tt>instproc</tt> <tt>init</tt> args {
+    ::Agent::Head [<tt>self</tt>]::myHead
+    ::Agent::Body [<tt>self</tt>]::myBody
   }
 </pre><P>
-We simply check whether the called method
-matches the given method name or not.
-
-<H3><A NAME="mixin_guards"></A> Mixin Guards</H3>
-<P>
-Similar to filters, there are mixin guards, defined with
-<tt>mixinguard</tt> and <tt>instmixinguard</tt>, or with
-<tt>-guard</tt> during mixin registration. Consider a simple example:
-there are a number of birds who have two mixins: Fly and Sing. For Fly
-there are limitations: a bird can only fly if it is at least two years
-old and is not a Penguin. Such problems are  be solved with
-mixin guards:
+Now all agents derived from the class have the two property objects
+aggregated after creation. But still they are changeable in a
+dynamical manner, e.g. with: 
 </P>
-
 <pre CLASS="code">
-  <tt>Class</tt> Fly
-  Fly <tt>instproc</tt> fly {} {<tt>puts</tt> "[my signature]: yippee, fly like an eagle!"}
+  Agent myAgent
+  myAgent::myHead <tt>destroy</tt>
+</pre><P>
+The agent turns into a headless agent. In companion of the
+introspection mechanisms such constructions could be very useful.
+Suppose, that in the virtual world the agents heads may be slashed
+from their bodies. The graphical system simply needs to ask with <tt>info
+children</tt> on the agent's object, whether it has a head or not and
+can choose the appropriate graphical representation. 
+</P>
 
-  <tt>Class</tt> Sing
-  Sing <tt>instproc</tt> sing {} {<tt>puts</tt> "[my signature]: what a difference a day makes"}
+<h3><A NAME="contains"></A>Simplified Syntax for Creating Nested Object Structures</h3>
 
-  <tt>Class</tt> Animal -parameter age
-  Animal <tt>instproc</tt> unknown args { puts "[my signature]: how should I $args?"}
-  Animal <tt>instproc</tt> signature {} {
-    <tt>return</tt> "[self] [my info class] ([my age] years)"
+To ease the generation of nested structures, one can use the
+predefined method <tt>contains</tt>. In essence, <tt>contains</tt>
+changes the namespace, where objects are created to the object,
+on which it is executed. In the example below, we create three
+nested rectangles, where two of these contain two more points.
+The outer rectangle is <tt>r0</tt> containing rectangle <tt>r1</tt>
+and <tt>r2</tt>.
+ 
+<pre CLASS="code">
+  <tt>Class</tt> Point <tt>-parameter</tt> {{x 100} {y 300}}
+  <tt>Class</tt> Rectangle <tt>-parameter</tt> {color}
+
+  Rectangle r0 -color pink <tt>-contains</tt> {
+    Rectangle r1 -color red <tt>-contains</tt> {
+      Point x1 -x 1 -y 2
+      Point x2 -x 1 -y 2
+    }
+    Rectangle r2 -color green <tt>-contains</tt> {
+      Point x1
+      Point x2
+    }
   }
 
-  <tt>Class</tt> Bird -superclass Animal
-  <tt>Class</tt> Penguine -superclass Bird
-  <tt>Class</tt> Parrot -superclass Bird
-  <tt>Class</tt> Duck -superclass Bird
+  ? {r0 color} pink
+  ? {r0 r1 color} red
+  ? {r0 r1 x1 x} 1
+  ? {r0 r1 x2 y} 2
+  ? {r0 r2 color} green
+</pre>
 
-  Parrot tweedy -age 1
-  Penguine pingo -age 5
-  Duck donald -age 4
-  Parrot lora -age 6
+<p>Every object in XOTcl is realized as a Tcl command. If nested
+objects are created, these commands are available as object specific
+methods.  So, instead of calling the contained rectangle r1 via the
+fully qualfied name <tt>::r0::r1</tt>, one can use <tt>r0
+r1</tt>. This is exactly the same situation as it arises, when e.g. a
+global Tcl proc <tt>proc o1 {} {...}</tt> and an XOTcl object o1
+(created via <tt>Object o1</tt>) is created. Both commands cannot
+coexist in the same namespace.
 
-  Bird <tt>instmixin</tt> {{Fly -guard {[my age] > 2 && ![my istype Penguine]}} Sing}
-</pre><P>
-An invocation like:
-</P>
+</p>
 
+<H3><A NAME="copy-move"></A>Copy/Move</H3>
+
+Often an object has to be copied/moved. This is a very useful
+functionality when XOTcl should be used as a prototyping language.
+The XOTcl method <tt>move</tt> provides this functionality. Another
+common behavior is implemented by the <tt>copy</tt> method which
+clones the actual object to a destination object via a deep copy operation.
+The two methods have the syntax:
+
 <pre CLASS="code">
-foreach bird {tweedy pingo donald lora} { $bird fly }
+  <em>objName</em> <tt>move</tt> <em>destination</em>
+  <em>objName</em> <tt>copy</tt> <em>destination</em>
 </pre><P>
-yields the following result:
-</P>
+
+Copy and move operations work with all object/class information, i.e.,
+information on filters, mixins, parameters, etc. are
+automatically copied. Copy and move are integrated with class nesting
+and object aggregations. All copy/move operations are deep copy
+operations: all nested objects/classes are automatically copied/moved,
+too.
+
+E.g. if we want to reuse an imperial march object of star wars for
+star wars 2, we can just copy the object:
 <pre CLASS="code">
-::tweedy ::Parrot (1 years): how should I fly?
-::pingo ::Penguine (5 years): how should I fly?
-::donald ::Duck (4 years): yippee, fly like an eagle!
-::lora ::Parrot (6 years): yippee, fly like an eagle!
+  starWars::imperialMarch <tt>copy</tt> starWars2::imperialMarch
 </pre>
 
-<P>
-There are similar introspection options for mixin guards as those for
-filter guards. In particular, we can use <tt>info mixinguard</tt> and
-<tt>info instmixinguard</tt> for getting the mixin guards for a
-particular mixin or instmixin respectively.
-</P>
+Note that move is implemented in current versions of xotcl
+as a copy plus subsequent destroy operation.
+<p>
 
-<H2><A NAME="updateinterceptors"></A>Querying, Setting, Altering Filter and Mixin Lists
-</H2>
 
-All methods <tt>mixin</tt>, <tt>instmixin</tt>, <tt>filter</tt> and
-<tt>instfilter</tt> have the same query and update interface. 
-<UL>
-<LI>If one of those methods is called without argument, it returns the current
-setting. <//LI>
-<LI>If it is called with one argument, the argument is used to
-set the specified list as indicated in the above examples. </LI>
-<LI>If these methods are called with more than one argument, the first argument
-is used to specify the action. Possible values for the action are
-<tt>set</tt>, <tt>get</tt>, <tt>add</tt> and <tt>delete</tt>. See below for 
-commonly used examples. 
-</UL>
-<P>
-<CENTER>	
-<TABLE BORDER=1>
-<TR><TD><tt>obj mixin</tt></TD>            <TD>same as: <tt>obj info mixin</tt></TD></TR>
-<TR><TD><tt>obj mixin {C1 C2}</tt></TD>    <TD>same as: <tt>obj mixin set {C1 C2}</tt></TD></TR>
-<TR><TD><tt>obj mixin set {C1 C2}</tt></TD><TD>sets the mixins for <tt>obj</tt></TD></TR>
-<TR><TD><tt>obj mixin get</tt></TD>        <TD>same as: <tt>obj info mixin</tt></TD></TR>
-<TR><TD><tt>obj mixin add C3</tt></TD>     <TD>adds the mixin <tt>C3</tt> on front of the mixin list</TD></TR>
-<TR><TD><tt>obj mixin add C3 end</tt></TD> <TD>adds the mixin <tt>C3</tt> at the end the mixin list</TD></TR>
-<TR><TD><tt>obj mixin add C3 3</tt></TD>   <TD>adds the mixin <tt>C3</tt> at the 3rd position</TD></TR>
-<TR><TD><tt>obj mixin delete ::C3</tt></TD><TD>removes the mixin <tt>C3</tt> from the mixin list.
-Use absolute class names. <tt>delete</tt> supports an optional flag <tt>-nocomplain</tt> that does not produce an error, when the specified class is not in the list. 
-</TD></TR>
-</TABLE>
-</CENTER>	
-</P>
-<P>
-Note, that the list of possible actions can be 
-extended by extending the class <tt>::xotcl::Relations</tt>.
-</P>
 
+
+
+
 <!-- PAGE BREAK -->
 
 <TABLE COLS=2 WIDTH=100% BORDER=0 CELLPADDING=2 CELLSPACING=0 BGCOLOR="#000055">
@@ -3209,29 +3827,60 @@
 	<IMG SRC="logo-100.jpg" NAME="Graphic9" ALIGN=RIGHT WIDTH=102 HEIGHT=42 BORDER=0></TD>
     </TR>
 </TABLE>
-<P>As you have seen from many examples, XOTcl's primary command for
+<P>As you have seen from many previous examples, XOTcl's primary command for
 method forwarding is the <tt>next</tt> primitive.  <tt>next</tt> calls
 the same-named method of the current object, usually with the same
 argument list. However, frequently method forwarding is required
 between different objects as well, commonly referred to as
-delegation.</P>
+<em>delegation</em>.</P>
 
-<P>In general, delegation can be achieved in XOTcl using procs or
-instprocs containing mostly a forward invocation to the target
-method. In several situations, forwarding is as well needed to general
-tcl commands, for example, if object oriented stubs are implemented on
+<P>In general, delegation can be achieved in XOTcl without any special construct
+using simple methods containing a few lines. However, In
+several situations, forwarding is as well needed to plain
+Tcl commands, for example, if object oriented stubs are implemented on
 base of non-oo function calls. These functions might access instance
 variables of the objects. XOTcl uses this functionality in various
 situations, such as for instance in the implementation of the
-<tt>append</tt>, <tt>trace</tt> or <tt>array</tt> methods.</p>
+<tt>set</tt>, <tt>unset</tt>, <tt>append</tt>, <tt>array</tt> methods among others.</p>
 
-<p>The methods <tt>forward</tt> and <tt>instforward</tt> address these
-requirements and provide an efficient implementation for these tasks.
-</p>
+<p>The fowarding functionality is suppored by XOTcl be the methods
+<tt>forward</tt> and <tt>instforward</tt> that address these requirements
+and provide an efficient implementation for these tasks.  </p>
 
-<P>We will introduce these forwarding mechanisms of XOTcl here based on
-examples.</P>
+<p>The forwarding command specifies that whenever <em>methodName</em> is called,
+this invocation is delegated to <em>callee</em>, where the actual argument list
+(from the invocation) is appended to the argument list specified in the forwarding command.
+Like for procs and instprocs, we can distinguish between <tt>forward</tt> and
+<tt>instforward</tt>, depending on we want to the method available for a single object
+of for the instances of a class.</p>
 
+<p>The general form of the forwarding commands is:
+<pre CLASS="code">
+  <em>obj</em> <tt> forward</tt> <em>methodName ?options? callee ?arglist?</em> 
+  <em>cls</em> <tt> instforward</tt> <em>methodName ?options? callee ?arglist?</em> 
+</pre>
+
+where valid options are <tt>-objscope</tt>, <tt>-methodprefix</tt>,
+<tt>-earlybinding</tt> and <tt>-default</tt>. The option
+<tt>-objscope</tt> is used to specify that the command should be
+executed in the scope of the calling object (i.e. instance variables apprear
+as local varibales), <tt>-methodprefix</tt> means that the called
+method should be prefixed with the specified string (to avoid name
+clashes), <tt>-earlybinding</tt> means that the function pointer of
+the specified command (callee) is take at invocation time (should only
+be done for (builtin) commands inplemented in C), and
+<tt>-default</tt> provides a means for providing default methods when
+none are specifed.</p>
+
+<p>Each of the arguments after the method name (including
+<tt>callee</tt>) can be be substituted an invocation time, or they are
+taken literally. The arguments to be substituted are starting always
+with a percent sign.  These arguemnts can be <tt>%self</tt>,
+<tt>%proc</tt>, <tt>%1</tt>, <tt>%argclindex</tt>, or <tt>%</tt>
+followed by a Tcl command, and it can be prefixed with a positional
+prefix <tt>%@</tt>.  We will introduce the usage of these options and
+argument substitutions based on examples.</P>
+
 <p>In our first example we define an object <tt>dog</tt> and an object
 <tt>tail</tt>. If the <tt>dog</tt> receives the call <tt>wag</tt> it
 delegates this call to the <tt>tail</tt> and returns its result.  In
@@ -3260,23 +3909,16 @@
   tail <tt>proc</tt> wag args { <tt>return</tt> $args }
   dog <tt>forward</tt> wag tail %proc
 </pre>
-<p>If the forwarder is called, it appends its current argument list to
-the called method. Therefore a call to<tt>dog wag 100</tt> returs the
-value <tt>100</tt>. The general form of the forwarder is:
-<pre CLASS="code">
-  <em>obj</em> <tt> forward</tt> <em> proc ?options? callee ?arglist?</em> 
-  <em>cls</em> <tt> instforward</tt> <em> proc ?options? callee ?arglist?</em> 
-</pre>
-where valid options are <tt>-objscope</tt>, <tt>-methodprefix</tt> and
-<tt>-default</tt>.  Each of the arguments of these methods can be
-<tt>%self</tt>, <tt>%proc</tt>, <tt>%1</tt>, or <tt>%</tt> followed by
-a tcl command, and it can be prefixed with a positional prefix
-<tt>%@</tt>. Usages of these forms are shown in the sequel.</p>
 
-<p>The following command shows the delegation to a Tcl command (instead of
-delegation to an object). We define a simple forwarder that forwards a call to the
-tcl command <tt>expr</tt> with some arguments.
+<p> With these definitions a call to "<tt>dog wag 100</tt>" calls
+actually "<tt>tail wag 100</tt>" which returns the result of
+<tt>100</tt>.</p>
 
+<p>The following command shows the delegation to a Tcl command
+(instead of delegation to an object). We define a simple forwarder
+that forwards a call to the Tcl command <tt>expr</tt> with some
+arguments.</p>
+
 <pre CLASS="code">
   <it>###########################################</it>
   <it># adding </it>
@@ -3287,7 +3929,7 @@
 The invocation <tt>obj addOne 5</tt> returns 6 as value.<p>
 
 
-<p>In our next example we want additionally that the tcl command
+<p>In our next example we want additionally that the Tcl command
 should to be evaluated in the context of the current object. This
 means that the method can easily access instance variables of the
 delegating object. We define a forwarder for the class <tt>X</tt> with
@@ -3315,7 +3957,7 @@
 <tt>%</tt>-substitution more advanced argument handling. This example
 sketches the implementation of the <tt>mixin add</tt>, <tt>mixin
 set</tt> methods as shown above. In order to obtain extensible
-subcommands (such as <tt>mixin add</tt>, <tt>mixin set</tt>, etc.), we
+subcommands (such as <tt>mixin add</tt>, <tt>mixin delete</tt>, etc.), we
 define an object for which the subcommands are defined as methods. We
 will use this object as callee for the appropriate methods. So, we
 define an object named <tt>mixin</tt> and define a forwarder with the
@@ -3371,7 +4013,7 @@
 </p>
 <pre CLASS="code">
   <it>###########################################</it>
-  <it># sketching extensibe info</it>
+  <it># sketching extensible info</it>
   <it>###########################################</it>
   <tt>Object</tt> Info
   Info <tt>proc</tt> @mixin {o} {
@@ -3443,7 +4085,57 @@
 some other %-substitution or a constant. The positional arguments 
 are evaluated from left to right and should be used in ascending order. 
 </p>
-<p>The following example defines a class <tt>cannel</tt> to use the
+
+<p>The following examples show a few usages of the positional arguments
+in the forwarder. The forwarders f1 to f5 are created, followed by
+one or more usages. The first argument of the usage is the call to
+to forewarder, the second argument is the result.
+</p>
+<pre CLASS="code">
+  <it>###########################################</it>
+  <it># forwarding with positional arguments</it>
+  <it>###########################################</it>
+  <tt>Object</tt> obj
+  obj <tt>forward</tt> f1 list {%@end 13}
+  ? {obj f1 1 2 3 } [<tt>list</tt> 1 2 3 13]
+
+  obj <tt>forward</tt> f2 list {%@-1 13}
+  ? {obj f2 1 2 3 } [<tt>list</tt> 1 2 13 3]
+
+  obj <tt>forward</tt> f3 list {%@1 13}
+  ? {obj f3 1 2 3 } [<tt>list</tt> 13 1 2 3]
+  ? {obj f3} [list 13]
+
+  obj <tt>forward</tt> f4 list {%@2 13}
+  ? {obj f4 1 2 3 } [<tt>list</tt> 1 13 2 3]
+
+  obj <tt>forward</tt> f5 {%@end 99} {%@0 list} 10
+  ? {obj f5} [<tt>list</tt> 10 99]
+  ? {obj f5 a b c} [<tt>list</tt> 10 a b c 99]
+</pre>
+
+<p> The construct <tt>%argclindex LIST</tt> can be used to substitute an argument
+depending on the number of arguments when the forwarder is
+invoked. For example, it is possible to call forward to a different
+method depending on how many arguments are specified. The number of arguments
+is used as an index in the specified list. When the number of arguments is larger
+than the number of elements in the specified list, an error is generated.</p>
+
+<pre CLASS="code">
+  <it>###############################################</it>
+  <it># substitution depending on number of arguments</it>
+  <it>###############################################</it>
+  obj <tt>forward</tt> f %self [list %argclindex [list a b c]]
+  obj <tt>proc</tt> a args {<tt>return</tt> [<tt>list</tt> [<tt>self proc</tt>] $args]}
+  obj <tt>proc</tt> b args {<tt>return</tt> [<tt>list</tt> [<tt>self proc</tt>] $args]}
+  obj <tt>proc</tt> c args {<tt>return</tt> [<tt>list</tt> [<tt>self proc</tt>] $args]}
+  ? {obj f} [list a {}]
+  ? {obj f 1 } [list b 1]
+  ? {obj f 1 2} [list c {1 2}]
+  ? {catch {obj f 1 2 3}} 1
+</pre>
+
+<p>Finally, the concluding example defines a class <tt>chan</tt> to use the
 I/O-commands in an OO-manner. The proc open is used to create a
 <tt>chan</tt> instance. For the channel object we provide the method
 <tt>close</tt> (to close a channel and to destroy the channel object),
@@ -3488,197 +4180,9 @@
   stderr puts "currently open streams: [chan info instances]"
 </pre>
 
-<!-- PAGE BREAK -->
 
-<TABLE COLS=2 WIDTH=100% BORDER=0 CELLPADDING=2 CELLSPACING=0 BGCOLOR="#000055">
-	<TR>
-		<TD WIDTH=75%>
-			<P><A NAME="nesting"></A><FONT COLOR="#ffffff"><FONT FACE="Arial, Helvetica"><FONT SIZE=6>Nested Classes
-			and Dynamic Object Aggregations </FONT></FONT></FONT>
-			</P>
-		</TD>
-		<TD>
-			<IMG SRC="logo-100.jpg" NAME="Graphic9" ALIGN=RIGHT WIDTH=102 HEIGHT=42 BORDER=0></TD>
-	</TR>
-</TABLE>
-<P>Most object-oriented analysis and design methods are based on the
-concepts of generalization and aggregation. Generalization is
-achieved through class hierarchies and inheritance, while static
-aggregation is provided through embedding. Since version 8.0 Tcl
-offers a namespace concept which can be used as a mechanism to
-provide dynamic aggregations. 
-</P>
-<P>A <EM>namespace</EM> provides an encapsulation of variable and
-procedure names in order to prevent unwanted name collisions with
-other system components. Each namespace has a unique identifier which
-becomes part of the fully qualified variable and procedure names.
-Namespaces are therefore already object-based in the terminology of
-Wegner. OTcl is object-oriented since it offers classes and class
-inheritance. Its objects are also namespaces, but an object is more
-than only a namespace. Therefore, two incompatible namespace concepts
-have existed in OTcl in parallel. 
-</P>
-<P>Extended OTcl combines the namespace concept of Tcl with the
-object concept of OTcl. Every object and every class in XOTcl is
-implemented as a separate Tcl namespace. The biggest benefit of this
-design decision aside from performance advantages is the ability to
-aggregate objects and nest classes. Contrary in OTcl every object has
-a global identifier. Through the introspection abilities of
-namespaces nested classes are also traceable at runtime and can be
-changed dynamically. In XOTcl objects are allowed to contain nested
-objects, which are dynamically changeable aggregates of the
-containing object. 
-</P>
 
 
-
-<H2><A NAME="nested_classes"></A>Nested Classes 
-</H2>
-<P>The notation for nested classes follows the syntax of Tcl
-namespaces by using ``::'' as a delimiter. For example the
-description of a oval carpet and a desk can nest inside of the
-<tt>OvalOffice</tt> class: 
-</P>
-<pre CLASS="code">
-  <tt>Class</tt> OvalOffice
-  <it># general carpet</it>
-  <tt>Class</tt> Carpet
-  <tt>Class</tt> OvalOffice::Desk
-  <it># special oval carpet - no name collision</it>
-  <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
-nesting structure of classes is available through the <tt>info</tt>
-instance method: 
-</P>
-<pre CLASS="code">
-  <em>className</em> <tt>info</tt> classchildren <em>?pattern?</em>
-  <em>className</em> <tt>info</tt> classparent
-</pre><P>
-The <tt>classchildren</tt> option returns a list of children, if one
-or more exist, otherwise it returns an empty string. <tt>classparent</tt>
-results in the name of the parent class, if the class is nested.
-Since nested classes are realized through namespaces, all
-functionality offered by Tcl's <tt>namespace</tt> command is usable
-from XOTcl as well. 
-</P>
-<H2><A NAME="obj-agg"></A>Dynamic Object Aggregations 
-</H2>
-<P>The nested classes only provide an aggregation of the descriptive
-not of the runtime properties of an object. We have pointed out the
-difference of object and class in XOTcl. Because of the splitting of a
-class into class and class-object it is possible to give each object
-its own namespace. The internal implementation of objects enable them
-to contain nested objects, which are aggregates of the containing
-object. In XOTcl these can be changed dynamically and introspected
-through the language support of dynamic object aggregations <a
-href="#xotcl-aggregation">[Neumann and Zdun 2000b]</a>. Suppose an
-object of the class <tt>Agent</tt> should aggregate some property
-objects of an agent, such as head and body:
-</P>
-<pre CLASS="code">
-  <tt>Class</tt>Agent
-  Agent myAgent
-
-  <tt>Class</tt> Agent::Head
-  <tt>Class</tt> Agent::Body
-
-  Agent::Head ::myAgent::myHead
-  Agent::Body ::myAgent::myBody
-</pre><P>
-Now the objects <tt>myHead</tt> and <tt>myBody</tt> are part of the
-<tt>myAgent</tt> object and they are accessible through a
-qualification using ``::'' (or through Tcl's namespace command). But
-in the common case they will be accessed, as introduced so far: the
-explicit full qualification is not necessary when such variables are
-being accessed from within XOTcl methods, since the object changes to
-its namespace. 
-</P>
-<P>The information about the part-of relationship of objects can be
-obtained exactly the same way as for classes through the 
-<tt>info</tt> interface: 
-</P>
-<pre CLASS="code">
-  <em>objName</em> <tt>info</tt> children <em>?pattern?</em>
-  <em>objName</em> <tt>info</tt> parent
-</pre>
-
-<H2><A NAME="nest_agg"></A>
-Relationship between Class Nesting and Object Aggregation 
-</H2>
-
-<P>The classes <tt>Head</tt> and <tt>Body</tt> are children of the
-<tt>Agent</tt> class. It is likely that all agents, interactive or
-not, have properties for head and body. This implies a static or
-predetermined relationship between class nesting and object
-aggregation. Such predetermination do not exist in XOTcl, but are
-simply build, when specifying the relationship in the constructor,
-e.g.: 
-</P>
-<pre CLASS="code">
-  Agent <tt>instproc</tt> <tt>init</tt> args {
-    ::Agent::Head [<tt>self</tt>]::myHead
-    ::Agent::Body [<tt>self</tt>]::myBody
-  }
-</pre><P>
-Now all agents derived from the class have the two property objects
-aggregated after creation. But still they are changeable in a
-dynamical manner, e.g. with: 
-</P>
-<pre CLASS="code">
-  Agent myAgent
-  myAgent::myHead <tt>destroy</tt>
-</pre><P>
-The agent turns into a headless agent. In companion of the
-introspection mechanisms such constructions could be very useful.
-Suppose, that in the virtual world the agents heads may be slashed
-from their bodies. The graphical system simply needs to ask with <tt>info
-children</tt> on the agent's object, whether it has a head or not and
-can choose the appropriate graphical representation. 
-</P>
-<P STYLE="margin-bottom: 0in">Note, that the not existing
-relationship means a great deal of freedom and dynamics, which goes
-together with the ideas behind OTcl, e.g. like the renunciation of
-protection mechanisms. This policy in programming language design
-means, on the one hand, ease of programming and more expressiveness,
-but, on the other hand, it contains no protection against bad
-software architectures or programming style. We believe that no such
-mechanisms could hinder the programmer to do silly things, so our
-policy was, to give the programmer rather more powerful constructs
-then to make decisions in his place. 
-</P>
-
-<H2><A NAME="copy_move"></A>Copy/Move
-</H2>
-
-Often an object has to be copied/moved. This is a very useful
-functionality when XOTcl should be used as a prototyping language.
-The XOTcl method <tt>move</tt> provides this functionality. Another
-common behavior is implemented by the <tt>copy</tt> method which
-clones the actual object to a destination object. The two methods have
-the syntax:
-
-<pre CLASS="code">
-  <em>objName</em> <tt>move</tt> <em>destination</em>
-  <em>objName</em> <tt>copy</tt> <em>destination</em>
-</pre><P>
-
-Copy and move operations work with all object/class information, i.e.,
-information on filters, mixins, parameters, etc. are
-automatically copied. Copy and move are integrated with class nesting
-and object aggregations. All copy/move operations are deep copy
-operations: all nested objects/classes are automatically copied/moved,
-too.
-
-E.g. if we want to reuse an imperial march object of star wars for
-star wars 2, we can just copy the object:
-<pre CLASS="code">
-  starWars::imperialMarch <tt>copy</tt> starWars2::imperialMarch
-</pre>
-
-
-
 <TABLE COLS=2 WIDTH=100% BORDER=0 CELLPADDING=2 CELLSPACING=0 BGCOLOR="#000055">
 	<TR>
 		<TD WIDTH=75%>
@@ -3930,260 +4434,7 @@
 and several other storage forms may be derived by sub-classing
 (therefore, all conform to the same storage access interface). 
 </P>
-<H2><A NAME="parameter"></A>Parameter</H2>
-<P>Classes may be equipped with <tt>parameter</tt> definitions which
-are automatically created for the convenient setting and querying of
-instance variables. Parameters may have a default value, e.g.: 
-</P>
-<pre CLASS="code">
-  <tt>Class</tt> Car <tt>-parameter</tt> {
-    owner
-    {doors 4}
-  }
-</pre><P>
-Each instance of class <tt>Car</tt> gets two instance variables
-defined. <tt>owner</tt> has no default value, and <tt>doors</tt>
-defaults to 4. E.g. the following defines a new person object with
-the two parameters set: 
-</P>
-<pre CLASS="code">
-  Car mercedes
-</pre><P>
-Additionally the <tt>parameter</tt> method automatically creates a
-new getter/setter instance method for each parameter -- same named to
-the parameter, which queries the parameter if it no argument is given
-or sets the parameter if with an given argument. E.g. a car with only
-two doors can be created by: 
-</P>
-<pre CLASS="code">
-  Car porsche -doors 2
-</pre><P>
-The owner of the first car is set by: 
-</P>
-<pre CLASS="code">
-  mercedes owner Marion
-</pre><P>
-and the doors of the first car can be queried (and printed to the
-screen) by: 
-</P>
-<pre CLASS="code">
-  <tt>puts</tt> "The mercedes got [mercedes doors] doors and is owned by [mercedes owner]"
-</pre><P>
-<tt>parameter</tt> are inherited by subclasses. The parameters
-specified in the class hierarchy are combined, default values
-can be redefined. Example:
-<pre CLASS="code">
-  <tt>Class</tt> Car <tt>-parameter</tt> {{doors 4} owner}
-  <tt>Class</tt> SportsCar <tt>-superclass</tt> Car <tt>-parameter</tt> {{doors 2}}
-  <tt>Class</tt> Limo <tt>-superclass</tt> Car
-  <tt>Class</tt> Porsche <tt>-superclass</tt> SportsCar
-  <tt>Class</tt> Mercedes <tt>-superclass</tt> Limo
 
-  Porsche p1 -owner peter
-  Mercedes m1 -owner marion
-  <tt>puts</tt> "[p1 owner]'s [p1 <tt>info</tt> class] has [p1 doors] doors"
-  <tt>puts</tt> "[m1 owner]'s [m1 <tt>info</tt> class] has [m1 doors] doors"
-</pre>
-<p>
-An entry of the list specified for <tt>parameter</tt> is either
-<ul>
-<li>
-  a single element denoting the name of the parameter (i.e. a method
-  to be defined to set (or get) an instance variable with the same
-  name, or it might be</li>
-<li>
-  a list of two elements denoting the name and a default value,
-  or it might be </li>
-<li>
-  a list of more than two elements (specification list), where it is
-  possible to call methods and to specify additional information about
-  the parameter to be set. For example, the following definition 
-<pre CLASS="code">
-  <tt>Class</tt> Car <tt>-parameter</tt> {{doors 4} owner}
-</pre>
-  is actually a short form for 
-<pre CLASS="code">
-  <tt>Class</tt> Car <tt>-parameter</tt> {{doors -default 4} owner}
-</pre>
-</li>
-</ul>
-<H4>Objects as Parameter</H4>
-<p>In the specification list of a parameter it is possible to specify
-a Class; Without the <tt>-Class</tt> given, a parameter denotes solely
-to an instance variable; when <tt>-Class</tt> is given an child object
-of the specified class is created, and the corresponding instance
-variable keeps the name of the object. The classes to be used for
-parameters must be instances of the meta-class
-<tt>::xotcl::Class::Parameter</tt>. 
-</p>
-<p>The following example shows how to define and use parameters of
-Class <tt>Point</tt> and <tt>Rectangle</tt>
-
-<pre CLASS="code">
-  ::xotcl::Class::Parameter Point <tt>-parameter</tt> {{x 0} {y 0} {z 0}}
-  ::xotcl::Class::Parameter Rectangle <tt>-parameter</tt> {
-    color
-    {leftCorner -Class "Point -x 0 -y 0" -default 1}
-    {rightCorner -Class "Point -x 10 -y 10" -default 1}
-  }
-  <tt>Class</tt> Container <tt>-parameter</tt> {
-    name
-    {startPoint -Class Point}  
-    {endPoint -Class Point}
-    {r -Class "Rectangle -color green" -default 1}
-  }
-  Container <tt>create</tt> c1 [<tt>list</tt> -startPoint -x 1 -y 2] [<tt>list</tt> -endPoint -z 3] 
-</pre>
-Similar to parameters without <tt>-Class</tt> they are created either
-when a default value is given or when they are specified during
-creation of the object. The default value is passed to the constructor
-of the parameter object. Therefore, upon creation of the Container
-in the example above, the following objects are created:
-<ul>
-<li>the Container <tt>c1</tt></li>
-<li>the Point <tt>startPoint</tt> as a child object of c1
-    (since it was specified in the creation of c1)</li>
-<li>the Point <tt>endPoint</tt> as a child object of c1
-    (since it was specified in the creation of c1)</li>
-<li>the Rectangle <tt>r</tt> as a child object of c1
-    (since it has a default value)</li>
-<li>the Points <tt>leftCorner</tt> and <tt>rightCorner</tt> 
-    as a child object of the rectangle
-    (since they have default values).</li>
-</ul>
-As all other parameters, parameters with classes can be
-reconfigured as well; the following commands sets the
-z coordinate of the <tt>endPoint</tt> of the container <tt>c1</tt>
-to 1.
-<pre CLASS="code">
-  c1 endPoint -z 1
-</pre>
-<p>Note that via <tt>someName -Class PC</tt> both, an instance of type
-<tt>PC</tt> is created and an instance variable with the name
-<tt>someName</tt> is created (as for all parameters), which will held
-in this case the name of the created object.
-</p>
-<H4>Setter and Getter Methods for Parameter</H4>
-By default, the methods defined to access the parameter values are
-instcommands implemented in C. However, it is possible to specify
-custom setter and getters that might perform additional tasks. There
-are two ways to specify custom setter/getter methods for parameters:
-<ul>
-<li>(a) the custom setter/getter methods can be defined as methods 
-   within the class hierarchy of the object, or </li>
-<li>(b) the custom getter/setter can
-   be specified on a different object. The set and get calls
-   are delegated to that object, which might be e.g. a 
-   database instance. </li>
-</ul>
-In both cases when the custom getters and/or setter are defined they
-will be called automatically from the standard setter/getter methods.
-In order to use approach (a) the parameter methods -getter 
-and -setter can be used to specify the custom getter and 
-and setter methods:
-<pre CLASS="code">
-  <tt>Class</tt> C <tt>-parameter</tt> {{a -setter myset -getter myget}}
-</pre>
-The methods myset and myget are called like set with
-one or two arguments. They are responsible for setting and
-retrieving the appropriate values. It is possible to 
-specify any one of these parameter methods. In the following
-example &quot;<tt>c1 myset a 100</tt>&quot; will be called by the 
-first line to set the value of a, &quot;<tt>c1 myget a</tt>&quot;
-will be called by the second line to obtain the value of a.
-<pre CLASS="code">
-  C c1 -a 100
-  c1 a
-</pre>
- In order to use approach (b) a parameter method <tt>-access</tt> is
- used to specify an object responsible for setting/getting the
- parameter's values. This has the advantage that the custom getter and
- setter methods can be inherited from a separate class hierarchy, such
- they can used for any object without cluttering its interface.
-<p>
-In order to keep the parameter specification short the access 
-object can contain instance variables setter or getter, naming its 
-the setter/getter methods. If these instance variables are not 
-in the access object, "set" is used per default for getter and
-setter. These default values can be still overridden by the 
-parameter methods -setter or -getter. Here is a simple example
-showing this mechanism.
-<pre CLASS="code">
-  <tt>Object</tt> db
-  db <tt>set</tt> setter myset
-  db <tt>set</tt> getter myget
-  db <tt>proc</tt> myset {o var value} { <tt>my</tt> <tt>set</tt> $var $value }
-  db <tt>proc</tt> myget {o var} { <tt>my</tt> <tt>set</tt> $var }
-
-  <tt>Class</tt> D <tt>-parameter</tt> {{x -access db}}
-  D d1
-  d1 x 100
-  <tt>puts</tt> x=[d1 x],vars=[db <tt>info</tt> vars]
-</pre>
-Note that myset and myget obtain the name of the object as well,
-such they can set theses instance variables in the object if 
-desired.
-
-<H4>Alternative Parameter Classes</H4>
-<p>For further customization, the class <tt>Class::Parameter</tt> 
-containing the described behavior can be as well extended (and 
-sub-classed).
-The basic idea is to make the parameter mechanism extensible in a
-similar way as the extension mechanisms work for normal object-oriented
-methods. One can extend the predefined <tt>Class::Parameter</tt> 
-class with <tt>someInstproc</tt> and use later
-</p>
-<pre CLASS="code">
-  C c1 {{a -default 1 -someInstproc x} ...}
-</pre>
-<p>
-or subclass it like:
-</p>
-<pre CLASS="code">
-  <tt>Class</tt> MyParameter <tt>-superclass</tt> Class::Parameter
-  <tt>Class</tt> X <tt>-parameterclass</tt> MyParameter <tt>-parameter</tt> ...
-</pre>
-<p>                                            
-
-Upon object initialization, the parameters are firstly evaluated for
-all mixins and then for the class hierarchy. E.g. in the following
-example:
-</p>
-<pre CLASS="code">
-  <tt>Class</tt> A <tt>-parameter</tt> {
-    {pcm 1}
-  }
-
-  <tt>Class</tt> B -instmixin A <tt>-parameter</tt> {
-    {cl 4}
-  }
-
-  B b
-</pre>
-<p>
-at first the mixin parameter 'pcm' is set, then the class parameter
-'cl'.  However, since parameters are applied before the '-' methods,
-the per-object mixin parameter defaults in the following example are
-not set by the standard initialization routine:
-</p>
-<pre CLASS="code">
-  <tt>Class</tt> C <tt>-parameter</tt> {
-    {pom 1}
-  }
-  B b <tt>-mixin</tt> C
-</pre>
-<p>
-If this parameter or any other parameter default, which is introduced
-later than the standard initialization routine, is required, then we
-can evaluate the parameter defaults manually, like:
-</p>
-<pre CLASS="code">
-  [B <tt>info</tt> parameterclass] searchDefaults b
-</pre>
-<p>
-This searches all default values for the object b which are defined on 
-mixins or on the class hierarchy.
-</P>
 <H2><A NAME="cmdCheck"></A>Checking Commands for being Objects,
 Classes, or Meta-Classes 
 </H2>
