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.
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.
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.
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.
In general, the Next Scripting Language (NX) differs from XOTcl +in the following respects:
-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. +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 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. +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.
++It is possible to use NX alias to register methods + under arbitrary names for arbitrary objects or classes. +
-The Next Scripting Language provides means of method - protection. Therefore developers have to define interfaces in - order to use methods from other objects. +NX provides means for method protection (method modifiers + public and protected). Therefore developers have to define + explicitly public interfaces in order to use methods from other + objects.
-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). +One can invoke in NX fully qualified methods to invoke + methods outside the precedence path.
-The Next Scripting Language provides much more orthogonal means to - define, reuse and introspect scripted and C-implemented methods. +One can define in NX ensemble methods (similar to + commands and subcommands) in a convenient way to provide + extensible, hierarchical naming of methods.
-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). +One can use in NX the same interface to query (introspect) + C-implemented and scripted methods/commands.
-The naming of the methods in the Next Scripting Language is much more - in line with the mainstream naming conventions in OO languages. +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 +
-The Next Scripting Language has a much smaller interface (less - predefined methods) than XOTcl (see Table 1), allthough the - expressability was increased in NX. +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. +
++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. +
+This comparison list compares mostly XOTcl 1 with NX, some features +are also available in XOTcl 2 (2a, 2c 2d, 3, 4).
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.
Another difference is the notation to refere to instance variables. In +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.
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.
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 @@ -874,14 +998,15 @@ Class) of XOTcl or NX into the current namespace.
The following sections are intended for reader familiar with XOTcl and show, how certain language Idioms of XOTcl can be expressed in NX. In some cases, multiple possible realizations are listed
When creating objects or classes, one should use the method create explicitly. In XOTcl, a default unknown handler was provided for classes, which create for every unknown method invocation an @@ -961,7 +1086,7 @@
In general, both XOTcl and NX support methods on the object level (per-object methods, i.e. methods only applicable to a single object) and on the class level (methods inherited to instances of the @@ -984,7 +1109,7 @@ (section 3.2.1) and C-defined methods (section 3.2.2). Section 3.2.3 introduces method protection, which is only supported by NX.
The following examples show the definition of a class and its methods in the init-block of a class (NX only), and the definition of methods via separate top level calls (XOTcl and NX).
This section describes various kinds of methods. The different kinds of methods are defined via different method-defining methods, which are summarized in the following table for XOTcl and NX.
NX supports the three method modifiers class, public and protected. All method modifiers can be written in front of every method defining command. The method modifier class is used to denote @@ -1438,7 +1563,7 @@
The Next Scripting Framework defines Tcl resolvers for method and variable names to implement object specific behavior. Within the bodies of scripted methods these resolver treat variable and function @@ -1449,7 +1574,7 @@
Note that the resolvers of the Next Scripting Framework can be used in the XOTcl 2.* environment as well.
In XOTcl, a method of the same object can be invoked via my, or in general via using the name of the object in front of the method name.
In NX, the own methods are called via the method name prefixed with a @@ -1516,7 +1641,7 @@
In general, the Next Scripting Language favors the access to an objects’s own instance variables over variable accesses of other objects. This means that in NX it is syntactically easier to access @@ -1773,7 +1898,7 @@