Index: doc/next-migration.txt
===================================================================
diff -u -r89cad338bc3a7ed0b43bde21193886d6a9b8c7b4 -r2b1c0832de70a62dfd45b4935eceedaf02777e7e
--- doc/next-migration.txt	(.../next-migration.txt)	(revision 89cad338bc3a7ed0b43bde21193886d6a9b8c7b4)
+++ doc/next-migration.txt	(.../next-migration.txt)	(revision 2b1c0832de70a62dfd45b4935eceedaf02777e7e)
@@ -1,10 +1,11 @@
 Migration Guide for the the Next Scripting Language
 ====================================================
 Gustaf Neumann <neumann@wu-wien.ac.at>
-v2.0, December 2010:
+v2.1, March 2011:
 Written for the Initial Release of the Next Scripting Framework.
 :Author Initials: GN
 :toc:
+:toclevels: 3
 :icons:
 :numbered:
 :website: http://www.xotcl.org/
@@ -19,7 +20,7 @@
 
 The Next Scripting Language (NX) is a successor of XOTcl 1 and is
 based on 10 years of experience with XOTcl in projects containing
-several hundert thousand lines of code.  While XOTcl was the first
+several hundert thousand lines of code. While XOTcl was the first
 language designed to provide language support for design patterns, the
 focus of the Next Scripting Framework and NX are on combining this
 with Language Oriented Programming. In many respects, NX was designed
@@ -35,7 +36,7 @@
 programming. The Next Scripting Frameworks provides C-level support
 for defining and hosting multiple object systems in a single Tcl
 interpreter. The whole definition of NX is fully scripted
-(e.g. defined in +nx.tcl+).  The Next Scripting Framework is shipped
+(e.g. defined in +nx.tcl+). The Next Scripting Framework is shipped
 with three language definitions, containing NX and XOTcl 2.  Most of
 the existing XOTcl 1 programs can be used without modification in the
 Next Scripting Framework by using XOTcl 2. The Next Scripting
@@ -52,80 +53,165 @@
 We expect that many user will find it attractive to upgrade
 from XOTcl 1 to XOTcl 2, and some other users will upgrade to NX.
 This document focuses mainly on the differences between XOTcl 1 and
-NX, but addresses as well potential incompatibilitied between XOTcl 1
+NX, but addresses as well potential incompatibilities between XOTcl 1
 and XOTcl 2. For an introduction to NX, please consult the NX tutorial.
 
 Differences Between XOTcl and NX
 -------------------------------
 
-In general, the Next Scripting Language (NX) differs from XOTcl in 
-the following respects:
+The Next Scripting Framework supports _Language Oriented Programming_
+by providing means to define potentially multiple object systems with
+different naming and functionality in a single interpreter.  This
+makes the Next Scripting Framework a powerful instrument for defining
+multiple languages such as e.g.  domain specific languages. This focus
+differs from XOTcl 1.
 
-- The Next Scripting Language favors a _stronger form of
-  encapsulation_ than XOTcl. Calling the own methods or accessing the
-  own instance variables is typographically easier and computationally
-  faster than these operations on other objects. This behavior is
-  achieved via resolversm which make some methods necessary in XOTcl
-  obsolete in NX (especially for importing instance variables). On the
-  other hand, XOTcl is complete symmetrical in this respect.
+Technically, the language framework approach means that the languages
+implemented by the Next Scripting Framework (most prominently XOTcl 2
+and NX) are typically fully scripted and can be loaded via the usual
+Tcl +package require+ mechanism.
 
-- The encapsulation of Next Scripting is stronger than in XOTcl but
-   still weak compared to languages like C++; a developer can still
-   access e.g. other variables via some idioms, but this _makes
-   accesses to other objects variables explicit_ and requires more
-   typing effort. Through the weak encapsulation a programmer should
-   be encouraged to implement methods to provide access to instance
-   variables.
+Some of the new features below are provided by the Next Scripting
+Framework, some are implemented via the script files for XOTcl 2 and
+NX.
 
-- The Next Scripting Language provides means of _method
-  protection_. Therefore developers have to define interfaces in order
-  to use methods from other objects.
+=== Features of NX
 
-- The Next Scripting Language provides _scripted init blocks_ for
-   objects and classes (replacement for the dangerous dash "-"
-   mechanism in XOTcl that allows to set variables and invoke methods
-   upon object creation).
+In general, the Next Scripting Language (NX) differs from XOTcl
+in the following respects:
 
-- The Next Scripting Language provides much more orthogonal means to
-   _define, reuse and introspect scripted and C-implemented methods_.
+. *Stronger Encapsulation:* The Next Scripting Language favors
+  a _stronger form of encapsulation_ than XOTcl. Calling the own
+  methods or accessing the own instance variables is typographically
+  easier and computationally faster than these operations on other
+  objects. This behavior is achieved via _resolvers_, which make some
+  methods necessary in XOTcl 1 obsolete in NX (especially for importing
+  instance variables).  The encapsulation of NX is stronger than in
+  XOTcl but still weak compared to languages like C++; a developer can
+  still access other objects' variables via some idioms, but NX _makes
+  accesses to other objects variables explicit_.  The requiredness to
+  make these accesses explicit should encourage developer to implement
+  well defined interfaces to provide access to instance variables.
 
-- The Next Scripting Language provides an _orthogonal framework for
-   parametrization of methods and objects_. While XOTcl 1 provided only
-   value-checkers for non-positional arguments for methods, the Next Scripting
-   Framework provides the same value checkers for positional argument
-   of methods, as well as for object parameters (`-parameter` in XOTcl 1).
+. *Additional Forms of Method Definition and Reuse:* 
+   The Next Scripting Language
+   provides much more orthogonal means to _define, reuse and
+   introspect_ scripted and C-implemented methods.
 
-- The Next Scripting Language has a much _smaller interface_ (less
-  predefined methods) than XOTcl:
+   .. It is possible to use NX +alias+ to register methods
+     under arbitrary names for arbitrary objects or classes.
 
-   * NX:
-[horizontal]
-Methods for Objects: :: 18
-Methods for Classes: :: 7
-Info methods for Objects: :: 14
-Info method for Classes: :: 6 
+   .. NX provides means for _method protection_ (method modifiers
+     +public+, +protected+ and +private+). Therefore developers have
+     to define explicitly public interfaces in order to use methods
+     from other objects.
 
-   * XOTcl:
-[horizontal]
-Methods for Objects: :: 52
-Methods for Classes: :: 24
-Info methods for Objects: :: 25
-Info method for Classes: :: 24 
+   .. One can invoke in NX fully qualified methods to invoke 
+     methods outside the precedence path.
 
-- The naming of the methods in the The Next Scripting Language is much more
-  in line with the mainstream naming conventions in OO languages.
+   .. One can define in NX _hierachical method names_ (similar to
+     commands and subcommands, called method ensembles) in a
+     convenient way to provide extensible, hierarchical naming of
+     methods.
 
+  .. One can use in NX the same interface to query (introspect)
+    C-implemented and scripted methods/commands.
+
+. *Orthogonal Parameterization:*
+   The Next Scripting Language provides an _orthogonal framework for
+   parametrization_ of methods and objects. 
+   .. In NX, the same argument parser is used for
+     * Scripted Methods
+     * C-implemented methods and Tcl commands
+     * Object Parametrization
+   ..  While XOTcl 1 provided only value-checkers for non-positional 
+     arguments for methods, the Next Scripting Framework provides 
+     the same value checkers for positional and non-positional
+     arguments of methods, as well as for positional and 
+     non-positional object parameters (`-parameter` in
+     XOTcl 1). 
+  .. While XOTcl 1 supported only non-positional arguments at the
+    begin of the argument list, these can be used now at arbitrary
+    positions.
+
+. *Value Checking:* 
+
+   .. The Next Scripting Language supports checking of the _input
+     parmeters_ and the _return values_ of scripted and C-implemented
+     methods and commands.
+
+   .. NX provides a set of predefined checkers (like e.g. +integer+,
+    +boolean+, +object+, ...) which can be extended by the
+     applications.
+
+  .. Value Checking can be used for _single_ and _multi-valued_
+    parameters. One can e.g. define a list of integers
+    with at least one entry by the parameter specification
+    +integer,1..n+.
+
+  .. Value Checking can be turned on/off globally or on the
+    method/command level.
+
+. *Scripted Init Blocks:* The Next Scripting Language provides
+   _scripted init blocks_ for objects and classes (replacement for the
+   dangerous dash "-" mechanism in XOTcl that allows to set variables
+   and invoke methods upon object creation).
+
+. *More Conventional Naming for Predefined Methods:* The naming of
+  the methods in the Next Scripting Language is much more in line with
+  the mainstream naming conventions in OO languages. While for example
+  XOTcl uses +proc+ and +instproc+ for object specific and inheritable
+  methods, NX uses simply +method+.
+
+. *Profiling Support:* The Next Scripting Language provides now two
+  forms of profiling
+   * Profiling via a DTrace provider (examples are e.g. in the dtrace
+      subdirectory of the source tree)
+   * Significantly improved built-in profiling (results can be
+     processed in Tcl).
+
+. *Significantly Improved Test Suite:* The regression test suite of 
+  Next Scripting Scripting framework contain now more than
+  5.000 tests, and order of magnitude more than in XOTcl 1.6
+
+. *Much Smaller Interface:* The Next Scripting Language has a much
+  _smaller interface_ (i.e.  provides less predefined methods) than
+  XOTcl (see Table 1), although the expressability was increased in
+  NX.
+
+.Comparison of the Number of Predefined Methods in NX and XOTcl
+[width="50%",frame="topbot",options="header,footer",cols="3,>1,>1"]
+|======================
+||NX|XOTcl
+|Methods for Objects           |20|  51
+|Methods for Classes           |  3|  24
+|Info-methods for Objects  |15|  25
+|Info-methods for Classes  |  6|  24
+|Total                                  | 44|124
+|======================
+
+This comparison list compares mostly XOTcl 1 with NX, some features
+are also available in XOTcl 2 (2a, 2c 2d, 3, 4).
+
+
+
+=== NX and XOTcl Scripts 
+
 Below is a small, introductory example showing an implementation of a
-class +Stack+ in NX and XOTcl. NX supports a block syntax, where the
-methods are defined during the creation of the class. The XOTcl syntax
-is slightly more redundant, since every definition of a method is a
-single toplevel command starting with the class name (also NX supports
-the style used in XOTcl).  In NX, all methods are per default
-protected (XOTcl does not support protection). In NX methods are
-defined in the definition of the class via +:method+ or +:public
-method+. In XOTcl methods are defined via the +instproc+ method.
+class +Stack+ in NX and XOTcl. The purpose of this first example is
+just a quick overview. We will go into much more detailed comparison
+in the next sections.
 
-Another difference is the notation to refere to instance variables. In
+NX supports a block syntax, where the methods are defined during the
+creation of the class. The XOTcl syntax is slightly more redundant,
+since every definition of a method is a single toplevel command
+starting with the class name (also NX supports the style used in
+XOTcl).  In NX, all methods are per default protected (XOTcl does not
+support protection). In NX methods are defined in the definition of
+the class via +:method+ or +:public method+. In XOTcl methods are
+defined via the +instproc+ method.
+
+Another difference is the notation to refer to instance variables. In
 NX, instance variable are named with a single colon in the front. In
 XOTcl, instance variables are imported using +instvar+.
 
@@ -140,9 +226,7 @@
    # Stack of Things
    #
 
-   :method init {} {
-     set :things ""
-   } 
+   :variable things ""
 
    :public method push {thing} {
       set :things [linsert ${:things} 0 $thing] 
@@ -169,7 +253,7 @@
    set things ""
 } 
 
-Stack instproc  push {thing} {
+Stack instproc push {thing} {
    my instvar things
    set things [linsert $things 0 $thing] 
    return $thing
@@ -183,9 +267,9 @@
 --------------------------------------------------
 |======================
 
-Using XOTcl 2.0 and the Next Scripting Language in a Single Interpreter
----------------------------------------------------------------------
 
+=== Using XOTcl 2.0 and the Next Scripting Language in a Single Interpreter
+
 In general, the Next Scripting Framework supports multiple object
 systems concurrently. Effectively, every object system has different
 base classes for creating objects and classes. Therefore, these object
@@ -209,28 +293,21 @@
 .Using Multiple Object Systems in a single Script
 [source,tcl]
 --------------------------------------------------
-   namespace eval mypackage {
+namespace eval mypackage {
 
-      package require XOTcl 2.0
+  package require XOTcl 2.0
 
-      # Import XOTcl into the current namespace
-      namespace import -force ::xotcl::*
+  # Define a class using XOTcl
+  xotcl::Class C1
+  C1 instproc foo {} {puts "hello world"}
 
-      # Define a class using XOTcl
-      Class C1
-      C1 instproc foo {} {puts "hello world"}
+  package require nx
 
-      package require nx
-
-      # Import NX into the current namespace; 
-      # "Class" will be after the command "::nx::Class"
-      namespace import -force ::nx::*
-
-      # Define a class using NX
-      Class create C2 {
-         :public method foo {} {puts "hello world"}
-      }
-   }
+  # Define a class using NX
+  nx::Class create C2 {
+    :public method foo {} {puts "hello world"}
+  }
+}
 --------------------------------------------------
 
 One could certainly create object or classes from the different object
@@ -252,11 +329,11 @@
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 
 When creating objects or classes, one should use the method +create+
-explicitly. In XOTcl, a default +unknown+ handler was provided for
+explicitly. In XOTcl, a default +unknown+ method handler was provided for
 classes, which create for every unknown method invocation an
 object/class with the name of the invoked method. This technique was
 convenient, but as well dangerous, since typos in method names lead
-easily to unexpected behavior. This default unknown handler is not
+easily to unexpected behavior. This default unknown method handler is not
 provided in NX (but can certainly be provided as a one-liner in NX by
 the application).
 
@@ -305,8 +382,8 @@
 object-specific methods. When the term (e.g. +method+) is used on a
 class, the method will be inherited (applicable to the instances of
 the class). When the term is used on an object, an object-specific
-method is defined. NX uses the method modifier +class-object+ to
-defined a class-method (method for the class-object).
+method is defined. NX uses the method modifier +class+ to
+define a class-specific method (method for the class object).
 
 Furthermore, both XOTcl and NX distinguish between scripted methods
 (section 3.2.1) and C-defined methods (section 3.2.2). Section 3.2.3
@@ -324,7 +401,7 @@
 
 |[source,tcl]
 ----------------
-# Define method 'foo' and class-object 
+# Define method 'foo' and class 
 # method 'bar' for a Class 'C' with separate 
 # toplevel commands
 
@@ -334,22 +411,22 @@
 ----------------
 |[source,tcl]
 ----------------
-# Define method and class-object method
+# Define method and class method
 # in the init-block of a class
 
 Class create C {
   :method foo args {...}
-  :class-object method bar args {...}
+  :class method bar args {...}
 }
 ----------------
 [source,tcl]
 ----------------
-# Define method and class-object method 
+# Define method and class method 
 # with separate commands
 
 Class create C
 C method foo args {...}
-C class-object method bar args {...}
+C class method bar args {...}
 ----------------
 
 |[source,tcl]
@@ -364,7 +441,7 @@
 
 |[source,tcl]
 ----------------
-# Define class-object method and set 
+# Define class method and set 
 # instance variable in the init-block of 
 # an object
 
@@ -375,7 +452,7 @@
 ----------------
 [source,tcl]
 ----------------
-# Define class-object method and set 
+# Define class method and set 
 # instance variable with separate 
 # commands
 
@@ -416,7 +493,7 @@
 #     method
 #     forward
 #     alias
-#     attribute
+#     property
 #
 # All these methods return method-handles.
 ----------------
@@ -430,7 +507,7 @@
 
 In NX forwarders are called +forward+. NX does not provide an own
 method to define variable accessors, but uses the Next Scripting
-Framework primitive +nsf::setter+ for it.
+Framework primitive +nsf::method::setter+ for it.
 
 [options="header",cols="asciidoc,asciidoc",frame="none",valign="middle"]
 |======================
@@ -452,7 +529,7 @@
 
 Class create C {
   :forward f1 ...
-  :class-object forward f2 ...
+  :class forward f2 ...
 }
 
 Object create o {
@@ -462,6 +539,10 @@
 
 |[source,tcl]
 ----------------
+# Define setter and getter methods in XOTcl.
+#
+# XOTcl provides methods for these.
+
 Class C
 C instparametercmd p1
 C parametercmd p2
@@ -472,14 +553,19 @@
 
 |[source,tcl]
 ----------------
-# Define setter and getter methods
+# Define setter and getter methods in NX.
+#
+# NX does not provide own methods, but uses 
+# the low level framework commands, since
+# application developer will only seldomly 
+# need it.
 
 Class create C
-::nsf::setter C p1
-::nsf::setter C -per-object p2
+::nsf::method::setter C p1
+::nsf::method::setter C -per-object p2
 
 Object create o 
-::nsf::setter o p3
+::nsf::method::setter o p3
 ----------------
 |======================
 
@@ -506,7 +592,7 @@
 
 Class create C {
   :alias a1 ...
-  :class-object alias a2 ...
+  :class alias a2 ...
 }
 
 Object create o {
@@ -519,11 +605,11 @@
 [[method-protect-example]]
 ==== Method Modifiers and Method Protection
 
-NX supports the three method modifiers +class-object+, +public+ and
-+protected+. All method modifiers can be written in front of every method
-defining command. The method modifier +class-object+ is used to denote
-class-object specific methods (see above). The concept of method
-protection is new in NX.
+NX supports four method modifiers +class+, +public+, +protected+ and
++private+. All method modifiers can be written in front of every
+method defining command. The method modifier +class+ is used to denote
+class-specific methods (see above). The concept of method protection
+is new in NX.
 
 [options="header",cols="asciidoc,asciidoc",frame="none",valign="middle"]
 |======================
@@ -533,41 +619,122 @@
 ----------------
 # Method modifiers
 #
-#   "class-object",
-#   "public", and
-#   "protected"
+#   "class",
+#   "public", 
+#   "protected", and
+#   "private"
 #
 # are not available
 ----------------
 |[source,tcl]
 ----------------
-# Method modifiers orthogonal over all kinds of methods
+# Method modifiers
 #
-# Method-definition-methods:
-#    method, forward, alias, attribute
-
+#   "class",
+#   "public",
+#   "protected"
+#
+# are applicable for all kinds of method 
+# defining methods:
+#
+#    method, forward, alias, property
+#
+# The modifier "private" is available for
+#
+#    method, forward, alias
+#
 Class create C {
   :/method-definiton-method/ ...
   :public /method-definiton-method/ ...
   :protected /method-definiton-method/ ...
-  :class-object /method-definiton-method/ ...
-  :protected class-object /method-definiton-method/ ...
-  :public class-object /method-definiton-method/ ...
+  :private /method-definiton-method/ ...
+  :class /method-definiton-method/ ...
+  :public class /method-definiton-method/ ...
+  :protected class /method-definiton-method/ ...
+  :private class /method-definiton-method/ ...
 }
 ----------------
 |======================
 
-While XOTcl does not provide method protection, in NX, all methods are
-defined per default as protected.
+XOTcl does not provide method protection. In NX, all methods are
+defined per default as protected. This default can be changed by the
+application developer in various ways. The command `::nx::configure
+defaultMethodCallProtection true|false` can be used to set the default
+call protection for scripted methods, forwarder and aliases, while
+`::nx::configure defaultPropertyCallProtection true|false` can set
+the default protection for properties. The defaults can be overwritten
+also e.g. on a class level.
 
-NX allows to configure the default call protection in various
-ways. The command `::nx::configure defaultMethodCallProtection
-true|false` can be used to set the default call protection for
-scripted methods, forwarder and aliases, while `::nx::configure
-defaultAttributeCallProtection true|false` can set the default
-protection for attributes.
+NX provides means for method hiding via the method modifier
++private+. Hidden methods can be invoked only via the +-local+ flag,
+which means: "call the specified method defined in the same
+class/object as the currently executing method". 
 
+[options="header",cols="asciidoc,asciidoc",frame="none",valign="middle"]
+|======================
+|XOTcl |Next Scripting Language
 
+|[source,tcl]
+----------------
+# XOTcl provides no means for method hiding
+----------------
+|[source,tcl]
+----------------
+# Hiding of methods via "private"
+#
+nx::Class create Base {
+  :private method baz {a b} {expr {$a + $b}}	
+  :public method foo {a b} {: -local baz $a $b}
+}
+    
+nx::Class create Sub -superclass Base {
+  :public method bar {a b} {: -local baz $a $b}
+  :private method baz {a b} {expr {$a * $b}}
+
+  :create s1
+}
+
+s1 foo 3 4  ;# returns 7
+s1 bar 3 4  ;# returns 12
+s1 baz 3 4  ;# unable to dispatch method 'baz'
+----------------
+|======================
+
+
+[[method-deletion]]
+==== Method and Property Deletion
+
+NX provides an explicit +delete+ method for the deletion of methods
+and properties.
+
+[options="header",cols="asciidoc,asciidoc",frame="none",valign="middle"]
+|======================
+|XOTcl |Next Scripting Language
+
+|[source,tcl]
+----------------
+# XOTcl provides only method deletion with 
+# the equivalent of Tcl's "proc foo {} {}"
+/obj/ proc foo {} {}
+/cls/ instproc foo {} {}
+
+# No support for property deletion
+----------------
+|[source,tcl]
+----------------
+# Deletion of Methods 
+#
+/obj/ delete method /name/
+/cls/ ?class? delete method /name/
+
+# Deletion of Properties
+/obj/ delete property /name/
+/cls/ ?class? delete property /name/
+----------------
+|======================
+
+
+
 === Resolvers
 
 The Next Scripting Framework defines Tcl resolvers for method and
@@ -615,7 +782,7 @@
   }
 }
 Object create o {
-  :method baz {} {...}
+  :public method baz {} {...}
 }
 ----------------
 |======================
@@ -633,11 +800,11 @@
 variables:
 
 - Import instance variables via +instvar+ and access variables via +$varName+
-- Set or get instance  variables via +my set varName ?value?+ or other 
+- Set or get instance variables via +my set varName ?value?+ or other 
    variable accessing methods registered on +xotcl::Object+ such as
    +append+, +lappend+, +incr+, etc.
 - Register same-named accessor functions and set/get values 
-   of instance variables via  +my varName ?value?+
+   of instance variables via +my varName ?value?+
 
 In NX, the favored approach to access instance variables is to use
 the name resolvers, although it is as well possible to import
@@ -765,7 +932,7 @@
 ----------------
 # Set instance variable of object obj to a 
 # value via resolver 
-# (preferred way: define attribute on obj)
+# (preferred way: define property on obj)
 
 /obj/ eval [list set /:varName/ ?value?]
 ----------------
@@ -817,35 +984,145 @@
 === Parameters
 
 While XOTcl 1 had very limited forms of parameters, XOTcl 2 and NX
-provide a generalized and highly orthogonal parameter handling with
-various kinds of value constraints (also called value checker). We
-divide the parameters into _Object Parameters_ (parameters used for
-initializing objects and classes, specified in XOTcl via the method
-+parameter+) and _Method Parameters_ (parameters passed to
-methods). The Next Scripting Framework provide a unified,
-C-implemented infrastructure to handle both, object and method
-parameters.
+provide a generalized and highly orthogonal parameter machinery
+handling various kinds of value constraints (also called value
+checkers). Parameters are used to specify, 
 
-Furthermore, the Next Scripting Framework provides
+- how objects and classes are initialized (we call these parameter types
+   _Object Parameters_), and
+- what values can be passed to methods (we call these _Method
+   Parameters_).
 
-- unified parameter checking (for object and method parameters) and 
-- return value checking
+Furthermore, parameters might be positional or non-positional, they
+might be optional or required, they might have a defined multiplicity,
+and value-types, they might be introspected, etc. The Next Scripting
+Framework provide a unified, C-implemented infrastructure to handle
+both, object and method parameters in the same way with a high degree
+of orthogonality.
 
-based on the same mechanisms.
+Object Parameters were specified in XOTcl 1 primarily via the method
++parameter+ in a rather limited way, XOTcl 1 only supported
+non-positional parameters in front of positional ones, there were no
+value constraints for positional parameters, no distinction between
+optional and required, or multiplicity.
 
-==== Object Parameters
+Furthermore, the Next Scripting Framework provides optionally _Return
+Value Checking_ based on the same mechanism to check whether some
+methods return always the values as specified.
 
-Object parameters are supported in XOTcl via the method
-+parameter+. Since the term "parameter" is underspecified, NX uses the
-term "attribute". To define multiple attributes in a short form, NX
-provides the method +attributes+.
+==== Instance Variables and Object Parameters
 
+Object parameters are used for specifying, how objects are
+initialized (i.e. how instance variables are initialized, what
+parameters can be passed in for initialization, what default values
+are used, etc.).  Object parameters are supported in XOTcl primarily
+via the method +parameter+, which is used in XOTcl to define multiple
+parameters via a list of parameter specifications. Since the term
+"parameter" is underspecified, NX uses a more differentiated
+terminology. NX distinguishes between instance variables with
+accessors (also called properties) and instance variables without
+accessors. To define a property, NX uses the method +property+, to
+define an instance variable without accessor, it uses the method
++variable+.  To define multiple properties in a short form (similar to
+XOTcl's +parameter+), NX provides the method +properties+.
+
+In a first step, we show the initialization of instance variables
+without accessors (using +variable+ in NX), and then the definition of 
+instance variables with accessors (using +property+).
+
 [options="header",cols="asciidoc,asciidoc",frame="none",valign="middle"]
 |======================
 |XOTcl |Next Scripting Language
 
 |[source,tcl]
 ----------------
+# Define that instances of the class have 
+# a instance variables "x" and "y" initialized
+# with some values
+
+Class Foo
+Foo instproc init args {
+   instvar x y
+   set x 1
+   set y 2
+}
+
+# Create instance of the class Foo
+Foo f1
+
+# Object f1 has instance variables 
+# x == 1 and y == 2
+----------------
+|[source,tcl]
+----------------
+
+# The method "variable" is similar in syntax 
+# to Tcl's "variable" command. During object 
+# creation, the definition are used for the 
+# initialization of the object.
+
+Class create Foo {
+  :variable x 1
+  :variable y 2
+}
+
+# Create instance of the class Foo
+Foo create f1
+
+# Object f1 has instance variables 
+# x == 1 and y == 2
+----------------
+|======================
+
+While XOTcl follows a procedural way to initialize variables via the
+constructor +init+, NX follows a more declarative approach. Note, that
+the variable definitions are inherited from superclasses, which is
+straightforward in NX, while in XOTcl, the constructor has to call
+explicitly the constructor of its superclasses.
+
+It is certainly as well possible to use constructors in NX in the same
+way as in XOTcl.
+
+NX uses the same mechanism to define class variables or object
+variables.
+
+[options="header",cols="asciidoc,asciidoc",frame="none",valign="middle"]
+|======================
+|XOTcl |Next Scripting Language
+
+|[source,tcl]
+----------------
+# No syntactic support for creating 
+# class variables
+----------------
+|[source,tcl]
+----------------
+
+# Define a class variable "V" with value 100 and
+# an instance variable "x". "class variable" works 
+# similar to "class method".
+
+Class create Foo {
+  :class variable V 100
+  :variable x 1
+}
+----------------
+|======================
+
+In the next step, we define properties, i.e. variables with accessors.
+
+XOTcl uses the method +parameter+ is a shortcut for creating multiple
+properties. For every parameter definition, XOTcl creates as well a
+slot object, keeping an extensible set of meta-data for every
+parameter.  Slot objects can be as well created in XOTcl directly via
+the method +slots+. NX provides a similar method named +properties+.
+
+[options="header",cols="asciidoc,asciidoc",frame="none",valign="middle"]
+|======================
+|XOTcl |Next Scripting Language
+
+|[source,tcl]
+----------------
 # Object parameter specified as a list (short form)
 # "a" has no default, "b" has default "1"
 
@@ -854,33 +1131,33 @@
 # Create instance of the class Foo
 Foo f1 -a 0
 
-# Object f1 has a == 0 and b == 1
+# Object f1 has instance variables 
+# a == 0 and b == 1
 ----------------
 |[source,tcl]
 ----------------
 # Object parameter specified as a list 
 # (short form); "a" has no default, 
 # "b" has default "1"
 
-Class create Foo -attributes {a {b 1}}
+Class create Foo -properties {a {b 1}}
 
 # Create instance of the class Foo
 Foo create f1 -a 0
 
-# Object f1 has a == 0 and b == 1
+# Object f1 has instance variables 
+# a == 0 and b == 1
 ----------------
 |======================
 
-In XOTcl the method +parameter+ is a shortcut for creating multiple
-slot objects. Slot objects can be as well created in XOTcl directly
-via the method +slots+ to provide a much richer set of
-meta-data for every attribute. 
+Since every property defines a slot object, NX provides as well a
+scripted initialization for every slot object. Therefore, NX uses
++property+ to define a single property, similar in syntax to method
+parameters (a braced pair to denote a variable with a default).  The
+method +property+ can be used in NX on the class and on the object
+level (in XOTcl: just on the class level). When an property is
+created, NX does actually three things:
 
-To make the definition of attributes more orthogonal, NX uses the
-method +attribute+ which can be used as well on the class and on the
-object level. When an attribute is created, NX does actually three
-things:
-
 . Create a slot object, which can be specified in more detail
   using the init-block of the slot object
 . Create an object parameter definition for the initialization of the
@@ -889,41 +1166,62 @@
 . register an accessor function (setter), for wich the usual
   protection levels (+public+ or +protected+) can be used.
 
+The method +variable+ in NX is similar to +property+, but it creates
+only slot objects in cases where needed, and it does not provide
+object parameters or accessors.
+
+We show first the definition of properties simliar to the
+functionality provided as well by XOTcl and show afterwards how to use
+value constraints, optional parameters, etc. in NX.
+
 [options="header",cols="asciidoc,asciidoc",frame="none",valign="middle"]
 |======================
 |XOTcl |Next Scripting Language
 
 |[source,tcl]
 ----------------
-# Object parameter specified via slots
+# Object parameters specified via slots
 
 Class Foo -slots {
    Attribute a
    Attribute b -default 1
 }
 
-# Create instance of the class Foo
+# Create instance of the class Foo and
+# provide a value for instance variable "a"
 Foo f1 -a 0
 
 # Object f1 has a == 0 and b == 1
 
+# Use the setter to alter instance variable "b"
+f1 b 100
+
+# Use the accessor to output the value
+puts [f1 b]
 ----------------
 
 |[source,tcl]
 ----------------
-# Object parameter specified via attribute 
-# methods (supports method modifiers and 
-# scripted configuration)
+# Object parameters specified via the method 
+# "property" (supports method modifiers and 
+# scripted configuration; see below)
 
 Class create Foo {
-   :attribute a
-   :attribute {b 1}
+   :property a
+   :property {b 1}
 }
 
-# Create instance of the class Foo
+# Create instance of the class Foo and
+# provide a value for instance variable "a"
 Foo create f1 -a 0
 
 # Object f1 has a == 0 and b == 1
+
+# Use the setter to alter instance variable "b"
+f1 b 100
+
+# Use the accessor to output the value
+puts [f1 b]
 ----------------
 
 
@@ -934,17 +1232,17 @@
 
 |[source,tcl]
 ----------------
-# Define object parameter at the class 
-# and object level
+# Define a class property and an object
+# property
 
 Class create C {
-  :attribute x
-  :attribute {y 1}
-  :class-object attribute oa1
+  :property x
+  :property {y 1}
+  :class property cp
 }
 
 Object create o {
-  :attribute oa2
+  :property op
 }
 ----------------
 
@@ -971,11 +1269,11 @@
 |[source,tcl]
 ----------------
 # Object parameter with scripted 
-# definition (init-block), defining an 
-# attribute specific type checker
+# definition (init-block), defining a
+# property specific type checker
 
 Class create Person {
-  :attribute sex {
+  :property sex {
     :type "sex"
     :method type=sex {name value} {
       switch -glob $value {
@@ -997,7 +1295,6 @@
 NX supports _value constraints_ (value-checkers) for object and method
 parameters in an orthogonal manner. NX provides a predefined set of
 value checkers, which can be extended by the application developer.
-
 In NX, the _value checking is optional_. This means that it is possible to
 develop e.g. which a large amount of value-checking and deploy the
 script with value checking turned off, if the script is highly
@@ -1009,46 +1306,47 @@
 
 |[source,tcl]
 ----------------
-# Value constraints for parameter 
-# not available 
+# No value constraints for parameter 
+# available 
 ----------------
 |[source,tcl]
 ----------------
 # Predefined value constraints: 
 #    object, class, alnum, alpha, ascii, boolean, 
-#    control,  digit, double, false, graph, integer, 
-#    lower, parameter, print, punct,  space, true, 
+#    control, digit, double, false, graph, integer, 
+#    lower, parameter, print, punct, space, true, 
 #    upper, wordchar, xdigit
 #
 # User defined value constraints are possible.
 # All parameter value checkers can be turned on 
 # and off.
 #
-# Define a boolean attribute and an integer 
-# attribute with a default firstly via "attributes", 
-# then with multiple "attribute"  statements.
+# Define a boolean property and an integer 
+# property with a default firstly via "properties", 
+# then with multiple "property" statements.
 
-Class create Foo -attributes {
+Class create Foo -properties {
    a:boolean
    {b:integer 1}
 }
 ----------------
 [source,tcl]
 ----------------
 Class create Foo {
-   :attribute a:boolean
-   :attribute {b:integer 1}
+   :property a:boolean
+   :property {b:integer 1}
 }
 ----------------
 |======================
 
 In XOTcl all object parameters were _optional_. Required parameters have
 to be passed to the constructor of the object.
 
-NX allows to define _optional_ and _required_ object
-attributes. Therefore, object parameters can be used as the single
-mechanism to parameterize objects. The constructors do not require any
-parameters.
+NX allows to define _optional_ and _required_ object parameters (as
+well as method parameters). Therefore, object parameters can be used
+as the single mechanism to parameterize objects. It is in NX not
+necessary (and per default not possible) to pass arguments to the
+constructor.
 
 [options="header",cols="asciidoc,asciidoc",frame="none",valign="middle"]
 |======================
@@ -1061,10 +1359,10 @@
 |[source,tcl]
 ----------------
 # Required parameter:
-# Define a required attribute "a" and a 
-# required boolean attribute "b"
+# Define a required property "a" and a 
+# required boolean property "b"
 
-Class create Foo -attributes {
+Class create Foo -properties {
    a:required
    b:boolean,required
 }
@@ -1073,8 +1371,8 @@
 ----------------
 
 Class create Foo {
-   :attribute a:required
-   :attribute b:boolean,required
+   :property a:required
+   :property b:boolean,required
 }
 ----------------
 |======================
@@ -1096,27 +1394,37 @@
 |[source,tcl]
 ----------------
 # Parameter with multiplicity
+#   ints is a list of integers, with default
+#   objs is a non-empty list of objects
+#   obj is a single object, maybe empty
 
-Class create Foo -attributes {
-  {ints:integer,0..n ""} ;# list of integers, with default
-   objs:object,1..n       ;# non-empty list of objects
-   obj:object,0..1        ;# single object, maybe empty
+Class create Foo -properties {
+  {ints:integer,0..n ""}
+   objs:object,1..n
+   obj:object,0..1
 }
 ----------------
 [source,tcl]
 ----------------
 Class create Foo {
-  :attribute {ints:integer,0..n ""}
-  :attribute objs:object,1..n 
-  :attribute obj:object,0..1
+  :property {ints:integer,0..n ""}
+  :property objs:object,1..n 
+  :property obj:object,0..1
 }
 ----------------
 |======================
 
+The Object parameters provided by a class for the initialization of
+instances can be introspected via +/cls/ info parameter+ (see
+<<info_parameter>>).
+
 ==== Method Parameters
 
-The method parameters specifications in XOTcl 1 were limited and
-allowed only value constraints for non positional arguments. 
+Method parameters are used to specify the interface of a single method
+(what kind of values may be passed to a method, what default values
+are provided etc.).  The method parameters specifications in XOTcl 1
+were limited and allowed only value constraints for non positional
+arguments.
 
 NX and XOTcl 2 provide value constraints for all kind of method parameters.
 While XOTcl 1 required non-positional arguments to be listed in front of
@@ -1159,7 +1467,10 @@
 
 |[source,tcl]
 ----------------
-# n.a.
+# Only leading non-positional parameters
+# are available; no optional positional 
+# parameters, no value constraints on 
+# positional parameters, no multiplicity, ...
 ----------------
 |[source,tcl]
 ----------------
@@ -1176,17 +1487,17 @@
   # positional parameters with value constraints
   :public method m2 {a:integer b:boolean} {
     #...
-  } 
+  }
 
   # optional positional parameter (trailing)
   :public method set {varName value:optional} {
     # ....
-   } 
+  }
 
   # parameter with multiplicity
   :public method m3 {-objs:object,1..n c:class,0..1} {
     # ...
-   } 
+  } 
 
   # In general, the same list of value 
   # constraints as for object parameter is 
@@ -1201,10 +1512,11 @@
 
 ==== Return Value Checking
 
-_Return value checking_ is a functionality that was not yet available in
-XOTcl 1. A return value checker assures that a method returns always a
-value satisfying some value constraints. Return value checkers can be defined on
-all forms of methods (scripted or C-implemented). Like for other value
+_Return value checking_ is a functionality available in the Next
+Scripting Framework, that was not yet available in XOTcl 1. A return
+value checker assures that a method returns always a value satisfying
+some value constraints. Return value checkers can be defined on all
+forms of methods (scripted or C-implemented). Like for other value
 checkers, return value checkers can be turned on and off.
 
 [options="header",cols="asciidoc,asciidoc",frame="none",valign="middle"]
@@ -1213,7 +1525,7 @@
 
 |[source,tcl]
 ----------------
-# n.a.
+# No return value checking available
 ----------------
 |[source,tcl]
 ----------------
@@ -1240,7 +1552,7 @@
 
  # Define a method that has to return a 
  # non-empty list of objects
- :public class-object method instances {} \
+ :public class method instances {} \
     -returns object,1..n {
    return [:info instances]
   }
@@ -1261,7 +1573,7 @@
 a per-class mixin, if the +mixin+ is registered on the object level,
 it is a object-level mixin. In both cases, the method +mixin+ is used.
 If a mixin is registered on the class object, one has to use the
-modifier +class-object+ (in the same way as e.g. for defining methods).
+modifier +class+ (in the same way as e.g. for defining methods).
 
 ==== Register Mixin Classes and Mixin Guards
 
@@ -1272,41 +1584,41 @@
 |[source,tcl]
 ----------------
 /cls/ instmixin ...
-/cls/ instmixinguard mixin /condition/
+/cls/ instmixinguard /mixin/ ?condition?
 ----------------
 |[source,tcl]
 ----------------
 # Register per-class mixin and guard for 
 # a class
 
 /cls/ mixin ...
-/cls/ mixin guard mixin /condition/
+/cls/ mixin guard /mixin/ ?condition?
 ----------------
 |[source,tcl]
 ----------------
 /cls/ mixin ...
-/cls/ mixin guard mixin /condition/
+/cls/ mixin guard /mixin/ ?condition?
 ----------------
 |[source,tcl]
 ----------------
 # Register per-object mixin and guard for 
 # a class
 
-/cls/ class-object mixin ...
-/cls/ class-object mixin guard mixin /condition/
+/cls/ class mixin ...
+/cls/ class mixin guard /mixin/ ?condition?
 ----------------
 |[source,tcl]
 ----------------
 /obj/ mixin ...
-/obj/ mixinguard mixin /condition/
+/obj/ mixinguard /mixin/ ?condition?
 ----------------
 |[source,tcl]
 ----------------
 # Register per-object mixin and guard for 
 # an object
 
 /obj/ mixin ...
-/obj/ mixin guard mixin /condition/
+/obj/ mixin guard /mixin/ ?condition?
 ----------------
 |======================
 
@@ -1318,15 +1630,15 @@
 |[source,tcl]
 ----------------
 /cls/ instfilter ...
-/cls/ instfilterguard filter /condition/
+/cls/ instfilterguard /filter/ ?condition?
 ----------------
 |[source,tcl]
 ----------------
 # Register per-class filter and guard for 
 # a class
 
 /cls/ filter ...
-/cls/ filter guard filter /condition/
+/cls/ filter guard /filter/ ?condition?
 ----------------
 |[source,tcl]
 ----------------
@@ -1338,21 +1650,21 @@
 # Register per-object filter and guard for 
 # a class
 
-/cls/ class-object filter ...
-/cls/ class-object filter guard filter /condition/
+/cls/ class filter ...
+/cls/ class filter guard /filter/ ?condition?
 ----------------
 |[source,tcl]
 ----------------
 /obj/ filter ...
-/obj/ filterguard filter /condition/
+/obj/ filterguard /filter/ ?condition?
 ----------------
 |[source,tcl]
 ----------------
 # Register per-object filter and guard for 
 # an object
 
 /obj/ filter ...
-/obj/ filter guard filter /condition/
+/obj/ filter guard /filter/ ?condition?
 ----------------
 |======================
 
@@ -1366,8 +1678,11 @@
 In NX, one can use e.g. always +info method+ with a subcommand and the
 framework tries to hide the differences as far as possible. So, one
 can for example obtain with +info method parameter+ the parameters of
-scripted and C-implemented methods the same way. In addition, NX
-provides means to query the type of a method.
+scripted and C-implemented methods the same way, one one can get the
+definition of all methods via +info method definition+ and one can get
+an manual-like interface description via +info method
+parametersyntax+. In addition, NX provides means to query the type of
+a method, and NX allows to filter by the type of the method.
 
 ==== List methods defined by classes
 
@@ -1509,8 +1824,8 @@
 
 ==== List class object specific methods
 
-When class-object specific properties are queried, NX required to use
-the modifier +class-object+ (like for the definition of the methods).
+When class specific properties are queried, NX required to use
+the modifier +class+ (like for the definition of the methods).
 In all other respects, this section is identical to the previous one.
 
 [options="header",cols="asciidoc,asciidoc",frame="none",valign="middle"]
@@ -1523,59 +1838,98 @@
 ----------------
 |[source,tcl]
 ----------------
-/cls/ class-object info methods ?pattern?
+/cls/ class info methods ?pattern?
 ----------------
 |[source,tcl]
 ----------------
 /cls/ info parametercmd ?pattern?
 ----------------
 |[source,tcl]
 ----------------
-/cls/ class-object info methods -methodtype setter ?pattern?
+/cls/ class info methods -methodtype setter ?pattern?
 ----------------
 |[source,tcl]
 ----------------
 /cls/ info procs ?pattern?
 ----------------
 |[source,tcl]
 ----------------
-/cls/ class-object info methods -methodtype scripted ?pattern?
+/cls/ class info methods -methodtype scripted ?pattern?
 ----------------
 |[source,tcl]
 ----------------
 # n.a.
 ----------------
 |[source,tcl]
 ----------------
-/cls/ class-object info methods -methodtype alias ?pattern?
+/cls/ class info methods -methodtype alias ?pattern?
 ----------------
 |[source,tcl]
 ----------------
 # n.a.
 ----------------
 |[source,tcl]
 ----------------
-/cls/ class-object info methods -methodtype forwarder ?pattern?
+/cls/ class info methods -methodtype forwarder ?pattern?
 ----------------
 |[source,tcl]
 ----------------
 # n.a.
 ----------------
 |[source,tcl]
 ----------------
-/cls/ class-object info methods -methodtype object ?pattern?
+/cls/ class info methods -methodtype object ?pattern?
 ----------------
 |[source,tcl]
 ----------------
 # n.a.
 ----------------
 |[source,tcl]
 ----------------
-/cls/ class-object info methods \
+/cls/ class info methods \
    -callprotection public\|protected ...
 ----------------
 |======================
 
+==== Check existence of a method
+
+NX provides multiple ways of checking, whether a method exists; one
+can use +info method exists+ to check, if a given method exists
+(return boolean), or one can use +info methods ?pattern?+, where
++pattern+ might be a single method name without wild-card
+characters. The method +info methods ?pattern?+ returns a list of
+matching names, which might be empty. These different methods appear
+appropriate depending on the context.
+
+[options="header",cols="asciidoc,asciidoc",frame="none",valign="middle"]
+|======================
+|XOTcl |Next Scripting Language
+
+|[source,tcl]
+----------------
+/obj\|cls/ info \
+   [inst](commands\|procs\|parametercmd) \
+   ?pattern?
+----------------
+|[source,tcl]
+----------------
+/obj/ info method exists /methodName/
+/obj/ info methods /methodName/
+----------------
+|[source,tcl]
+----------------
+/obj\|cls/ info \
+   [inst](commands\|procs\|parametercmd) \
+   ?pattern?
+----------------
+|[source,tcl]
+----------------
+/cls/ ?class? info method exists /methodName/
+/cls/ ?class? info methods /methodName/
+----------------
+|======================
+
+
 ==== List callable methods
 
 In order to obtain for an object the set of artefacts defined in the
@@ -1630,12 +1984,16 @@
 |[source,tcl]
 ----------------
 # List slot objects defined for obj
-/obj/ info lookup slots
-# Returns list of slot objects 
+# -source might be all\|application\|baseclasses
+# -type is the class of the slot object
+
+/obj/ info lookup slots ?-type ...? ?-source ...? ?pattern?
+
+# Returns list of slot objects
 ----------------
 |======================
 
-==== List object/class where some method is defined
+==== List object/class where a specified method is defined
 
 +info lookup+ can be used as well to determine, where exactly an
  artefact is located. One can obtain this way a method handle, where 
@@ -1832,8 +2190,135 @@
 |======================
 
 For definition of class object specific methods, use the modifier
-+class-object+ as shown in examples above.
++class+ as shown in examples above.
 
+
+==== List Slots and their definitions
+
+
+[options="header",cols="asciidoc,asciidoc",frame="none",valign="middle"]
+|======================
+|XOTcl |Next Scripting Language
+
+|[source,tcl]
+----------------
+# n.a.
+----------------
+|[source,tcl]
+----------------
+# Return list of slots objects defined on the
+# object or class
+#
+# -source might be all\|application\|baseclasses
+# -type is the class of the slot object
+# -closure includes slots of superclasses
+
+/obj/ info slot objects ?-type ...? ?pattern?
+/cls/ class info slot objects ?-type ...? ?pattern?
+/cls/ info slot objects \
+   ?-type value? ?-closure? ?-source value? ?pattern?
+----------------
+|[source,tcl]
+----------------
+# n.a.
+----------------
+|[source,tcl]
+----------------
+# List definition of slots 
+
+/obj/ info slot definition \
+   ?-type value? ?pattern?
+/cls/ class info slot definition \
+   ?-type value? ?pattern?
+/cls/ info slot definition \
+   ?-type value? ?-closure? ?-source value? ?pattern?
+----------------
+|[source,tcl]
+----------------
+/cls/ info parameter
+----------------
+|[source,tcl]
+----------------
+# "info properties" is a short form of "info slot definiton"
+
+/cls/ info properties \
+   ?-type value? ?-closure? ?-source value? ?pattern?
+----------------
+|[source,tcl]
+----------------
+# n.a.
+----------------
+|[source,tcl]
+----------------
+# List names of slots 
+
+/obj/ info slot names \
+   ?-type value? ?pattern?
+/cls/ class info slot names \
+   ?-type value? ?pattern?
+/cls/ info slot names \
+   ?-type value? ?-closure? ?-source value? ?pattern?
+----------------
+|[source,tcl]
+----------------
+# n.a.
+----------------
+|[source,tcl]
+----------------
+# List reachable slot objects defined for obj
+# -source might be all\|application\|baseclasses
+# -type is the class of the slot object
+
+/obj/ info lookup slots \
+   ?-type ...? ?-source ... ?pattern?
+
+# Returns list of slot objects
+----------------
+|======================
+
+
+[[info_parameter]]
+==== List Object parameters
+
+[options="header",cols="asciidoc,asciidoc",frame="none",valign="middle"]
+|======================
+|XOTcl |Next Scripting Language
+
+|[source,tcl]
+----------------
+# n.a.
+----------------
+|[source,tcl]
+----------------
+# Return parameter(s) provided by class for 
+# its instances; defines, how objects of this
+# class can be configured. If name is provided
+# only the named object parameter is returned
+# otherwise the full list. 
+#
+#
+# Return object parameters with leading dashes
+# for non-positional object parameters and 
+# defaults
+/cls/ info parameter list ?name?
+
+# Return just the names of the parameters
+/cls/ info parameter names ?name?
+
+# Return the full parameter specs
+/cls/ info parameter definition ?name?
+
+# Return the slot object(s)
+/cls/ info parameter slot ?name?
+
+# Return in the Tcl parameter syntax
+/cls/ info parameter syntax ?name?
+----------------
+|======================
+
+
+
+
 ==== List Filter or Mixins
 
 In NX all introspection options for filters are grouped under +info
@@ -1872,7 +2357,7 @@
 ----------------
 |[source,tcl]
 ----------------
-/cls/ class-object info filter methods \
+/cls/ class info filter methods \
    ?-guards? ?-order? ?pattern?
 ----------------
 |[source,tcl]
@@ -1881,7 +2366,7 @@
 ----------------
 |[source,tcl]
 ----------------
-/cls/ class-object info filter guard /name/
+/cls/ class info filter guard /name/
 ----------------
 |[source,tcl]
 ----------------
@@ -1908,7 +2393,7 @@
 |[source,tcl]
 ----------------
 /obj/ info mixin classes \
-   ?-guards? ?-order? ?pattern?
+   ?-guards? ?-heritage? ?pattern?
 ----------------
 |[source,tcl]
 ----------------
@@ -1924,16 +2409,16 @@
 ----------------
 |[source,tcl]
 ----------------
-/cls/ class-object info mixin classes \
-   ?-guards? ?-order? ?pattern?
+/cls/ class info mixin classes \
+   ?-guards? ?-heritage? ?pattern?
 ----------------
 |[source,tcl]
 ----------------
 /cls/ info mixinguard /name/
 ----------------
 |[source,tcl]
 ----------------
-/cls/ class-object info mixin guard /name/
+/cls/ class info mixin guard /name/
 ----------------
 |[source,tcl]
 ----------------
@@ -1943,7 +2428,7 @@
 |[source,tcl]
 ----------------
 /cls/ info mixin classes \
-   ?-guards? ?-order? ?pattern?
+   ?-closure? ?-guards? ?-heritage? ?pattern?
 ----------------
 |[source,tcl]
 ----------------
@@ -1957,7 +2442,7 @@
 
 ==== List definition of methods defined by aliases, setters or forwarders
 
-As mentioned earlier, +info method definition" can be used on every
+As mentioned earlier, +info method definition+ can be used on every
 kind of method.
 
 [options="header",cols="asciidoc,asciidoc",frame="none",valign="middle"]
@@ -1971,21 +2456,14 @@
 |[source,tcl]
 ----------------
 /obj/ info method definition /methodName/
+/cls/ ?class? info method definition /methodName/
 ----------------
-|[source,tcl]
-----------------
-# n.a.
-----------------
-|[source,tcl]
----------------
-/cls/ info method definition /methodName/
-----------------
 |======================
 
 
 ==== List Method-Handles
 
-NX supports  _method-handles_ to provide means to obtain further
+NX supports _method-handles_ to provide means to obtain further
 information about a method or to change maybe some properties of a
 method. When a method is created, the method creating method returns
 the method handle to the created method.
@@ -2000,16 +2478,29 @@
 ----------------
 |[source,tcl]
 ----------------
+#
+# List the method handle of the specified method, 
+# can be used e.g. for aliases. "handle" is the short 
+# form of "definitionhandle".
+#
 /obj/ info method handle /methodName/
+/cls/ ?class? info method handle /methodName/
+#
+# For ensemble methods (method name contains 
+# spaces) one can query as well the registration 
+# handle, which is the handle to the root of the
+# ensemble; the definiton handle points to the 
+# leaf of the ensemble.
+#
+/obj/ info method registrationhandle /methodName/
+/cls/ ?class? info method registrationhandle /methodName/
+#
+# For aliases, one can query the original definition
+# via "info method origin"
+#
+/obj/ info method origin /methodName/
+/cls/ ?class? info method origin /methodName/
 ----------------
-|[source,tcl]
-----------------
-# n.a.
-----------------
-|[source,tcl]
-----------------
-/cls/ ?class-object? info method handle /methodName/
-----------------
 |======================
 
 ==== List type of a method
@@ -2035,7 +2526,7 @@
 ----------------
 |[source,tcl]
 ----------------
-/cls/ ?class-object? info method type /methodName/
+/cls/ ?class? info method type /methodName/
 ----------------
 |======================
 
@@ -2086,6 +2577,7 @@
 ----------------
 |======================
 
+
 ==== Check properties of object and classes
 
 Similar as noted before, NX uses rather a hierarchical approach of
@@ -2137,11 +2629,11 @@
 ----------------
 |[source,tcl]
 ----------------
-/obj/ isobject /obj/
+/obj/ object::exists /obj/
 ----------------
 |[source,tcl]
 ----------------
-::nsf::isobject /obj/
+::nsf::object::exists /obj/
 ----------------
 |======================
 
@@ -2301,7 +2793,7 @@
 
 In contrary to XOTcl, NX provides no pre-registered methods for
 assertion handling. All assertion handling can e performed via the
-Next Scripting primitive +nsf::assertion+.
+Next Scripting primitive +nsf::method::assertion+.
 
 [options="header",cols="asciidoc,asciidoc",frame="none",valign="middle"]
 |======================
@@ -2313,63 +2805,63 @@
 ----------------
 |[source,tcl]
 ----------------
-::nsf::assertion /obj/ check /checkptions/
+::nsf::method::assertion /obj/ check /checkptions/
 ----------------
 |[source,tcl]
 ----------------
 /obj/ info check
 ----------------
 |[source,tcl]
 ----------------
-::nsf::assertion /obj/ check
+::nsf::method::assertion /obj/ check
 ----------------
 |[source,tcl]
 ----------------
 /obj/ invar /conditions/
 ----------------
 |[source,tcl]
 ----------------
-::nsf::assertion /obj/ object-invar /conditions/
+::nsf::method::assertion /obj/ object-invar /conditions/
 ----------------
 |[source,tcl]
 ----------------
 /obj/ info invar
 ----------------
 |[source,tcl]
 ----------------
-::nsf::assertion /obj/ object-invar
+::nsf::method::assertion /obj/ object-invar
 ----------------
 |[source,tcl]
 ----------------
 /cls/ instinvar /conditions/
 ----------------
 |[source,tcl]
 ----------------
-::nsf::assertion /cls/ class-invar /conditions/
+::nsf::method::assertion /cls/ class-invar /conditions/
 ----------------
 |[source,tcl]
 ----------------
 /cls/ info instinvar
 ----------------
 |[source,tcl]
 ----------------
-::nsf::assertion /cls/ class-invar
+::nsf::method::assertion /cls/ class-invar
 ----------------
 |[source,tcl]
 ----------------
 /cls/ invar /conditions/
 ----------------
 |[source,tcl]
 ----------------
-::nsf::assertion /cls/ object-invar /conditions/
+::nsf::method::assertion /cls/ object-invar /conditions/
 ----------------
 |[source,tcl]
 ----------------
 /cls/ info invar
 ----------------
 |[source,tcl]
 ----------------
-::nsf::assertion /cls/ object-invar
+::nsf::method::assertion /cls/ object-invar
 ----------------
 |======================
 
@@ -2380,7 +2872,7 @@
 protected method can be only called from an object of that class,
 while public methods can be called from every object. The method
 protection can be used to every kind of method, such as e.g. scripted
-methods, aliases, forwarders, or attributes. For invocations,
+methods, aliases, forwarders, or accessors. For invocations,
 the most specific definition (might be a mixin) is used for
 determining the protection.
 
@@ -2401,10 +2893,12 @@
 ==== Parameter usage without a value
 
 In XOTcl 1, it was possible to call a parameter method during object
-creation via the -param without a value (in the example below `-x`. 
+creation via the dash-interface without a value (in the example below `-x`). 
 
 [source,tcl]
 ----------------
+# XOTcl example
+
 Class Foo -parameter {x y}
 Foo f1 -x -y 1
 ----------------
@@ -2420,50 +2914,55 @@
 XOTcl 2, the variable won't be set.
 [source,tcl]
 ----------------
+# XOTcl example
+
 Class Foo -parameter {{x 1}}
 Class Bar -superclass Foo -parameter x
 Bar b1
 ----------------
 
+==== Changing classes and superclasses
 
-=== Calling objects via method interface
+NX does not define the methods +class+ and +superclass+ but allows to
+alter the class/superclass via +configure+. The class and superclass
+can be certainly queried in all variants with +info class+ or +info superclass+.
+[source,tcl]
+----------------
+# NX example
 
-Since the Next Scripting Framework supports the so-called ensemble
-objects, which ease the definition of sub-methods substantially,
-objects registered as methods have different semantics. In XOTcl 1, it
-was possible to call e.g. a method foo of the slot object
-`Foo::slot::ints` via the following two interfaces the same way:
+nx::Class create Foo
+Foo create f1
+# now alter the class of object f1
+f1 configure -class nx::Object
 
-[source,tcl]
+# alternate approach via Next Scripting Framework
+::nsf::relation f1 class ::nx::Object
 ----------------
-Foo::slot::ints foo ...
-Foo slot ints foo ... 
-----------------
 
-In the Next Scripting Framework, only the first form has the same
-semantic as before. In the second form (invocation of objects via
-method interface) has now the ensemble object semantics. This means
-that in the second case the current object of method foo is now Foo
-instead of ints.
+==== Info heritage
++info heritage+ returns in XOTcl 1 the transitive superclass
+hierarchy, which is equivalent with +info superclass -closure+ and
+therefore not necessary. In XOTcl 2 (and NX), +info heritage+ includes
+as well the transitive per-class mixins.
 
 === Slots
 
 All slot objects (also XOTcl slot objects) are now next-scripting
 objects of baseclass `::nx::Slot`. The name of the experimental
 default-setter `initcmd` was changed to `defaultcmd`. Code directly
-working on the slots objects has to be adapted.  
+working on the slots objects has to be adapted. 
 
-=== Obsolete commands
+=== Obsolete Commands
 
 Parameter-classes were rarely used and have been replaced by the more
 general object parameterization. Therefore, `cl info parameterclass` has
-been removed.  
+been removed. 
 
 === Stronger Checking
 
 The Next Scripting Framework performs stronger checking than XOTcl 1
 For example, the requiredness of slots in XOTcl 1 was just a
-comment, while XOTcl 2 enforces it.  
+comment, while XOTcl 2 enforces it. 
 
 === Exit Handlers
 
@@ -2472,6 +2971,7 @@
 
 [source,tcl]
 ----------------
+# NX example
 ::nsf::exithandler set|get|unset ?arg?
 ----------------