Migration Guide for the the Next Scripting Language ==================================================== Gustaf Neumann v2.1, March 2011: Written for the Initial Release of the Next Scripting Framework. :Author Initials: GN :toc: :icons: :numbered: :website: http://www.xotcl.org/ .Abstract ***************************************************************************** This document describes the differences between the Next Scripting Language Framework and XOTcl 1. In particular, it presents a migration guide from XOTcl 1 to NX, and presents potential incompatibilities beween XOTcl 1 and XOTcl 2. ***************************************************************************** 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 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 to ease the learning of the language by novices (by using a more mainstream terminology, higher orthogonality of the methods, less predefined methods), to improve maintainability (remove sources of common errors) and to encourage developer to write better structured programs (to provide interfaces) especially for large projects, where many developers are involved. The Next Scripting Language is based on the Next Scripting Framework which was developed based on the notion of language oriented 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 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 Framework requires Tcl 8.5 or newer. Although NX is fully scripted (as well as XOTcl 2), our benchmarks show that scripts based on NX are often 2 or 4 times faster than the counterparts in XOTcl 1. But speed was not the primary focus on the Next Scripting Environment: The goal was primarily to find ways to repackage the power of XOTcl in an easy to learn environment, highly orthogonal environment, which is better suited for large projects, trying to reduce maintenance costs. 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 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 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. - 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 means of _method protection_. Therefore developers have to define 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). - The Next Scripting Language provides much more orthogonal means to _define, reuse and introspect scripted and C-implemented 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). - The naming of the methods in the Next Scripting Language is much more in line with the mainstream naming conventions in OO languages. - The Next Scripting Language has a much _smaller interface_ (less predefined methods) than XOTcl (see Table 1), allthough the expressability was increased in NX. .Comparison of the Number of Methods in NX and XOTcl [width="50%",frame="topbot",options="header,footer",cols="3,>1,>1"] |====================== ||NX|XOTcl |Methods for Objects |17| 52 |Methods for Classes | 4| 24 |Info-methods for Objects |14| 25 |Info-methods for Classes | 6| 24 |Total | 41|125 |====================== 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 NX, instance variable are named with a single colon in the front. In XOTcl, instance variables are imported using +instvar+. [options="header",cols="asciidoc,asciidoc",frame="none"] |====================== |Stack example in NX |Stack example in XOTcl |[source,tcl] -------------------------------------------------- Class create Stack { # # Stack of Things # :method init {} { set :things "" } :public method push {thing} { set :things [linsert ${:things} 0 $thing] return $thing } :public method pop {} { set top [lindex ${:things} 0] set :things [lrange ${:things} 1 end] return $top } } -------------------------------------------------- |[source,tcl] -------------------------------------------------- # # Stack of Things # Class Stack Stack instproc init {} { my instvar things set things "" } Stack instproc push {thing} { my instvar things set things [linsert $things 0 $thing] return $thing } Stack instproc pop {} { my instvar things set top [lindex $things 0] set things [lrange $things 1 end] } -------------------------------------------------- |====================== 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 systems can have different different interfaces and names of built-in methods. Currently, the Next Scripting Framework is packaged with three object systems: - NX - XOTcl 2.0 - TclCool XOTcl 2 is highly compatible with XOTcl 1, the language NX is described below in more details, the language TclCool was introduced in Tip#279 and serves primarily an example of a small OO language. A single Tcl interpreter can host multiple Next Scripting Object Systems at the same time. This fact makes migration from XOTcl to NX easier. The following example script shows to use XOTcl and NX in a single script: .Using Multiple Object Systems in a single Script [source,tcl] -------------------------------------------------- namespace eval mypackage { package require XOTcl 2.0 # Define a class using XOTcl xotcl::Class C1 C1 instproc foo {} {puts "hello world"} package require nx # 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 systems via fully qualified names (e.g. using e.g. `::xotcl::Class` or `::nx::Class`), but for migration for systems without explicit namespaces switching between the object systems eases migration. "Switching" between XOTcl and NX effectively means the load some packages (if needed) and to import either the base classes (Object and Class) of XOTcl or NX into the current namespace. XOTcl Idioms in the Next Scripting Language --------------------------------------------- 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 Defining Objects and Classes ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 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 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 provided in NX (but can certainly be provided as a one-liner in NX by the application). [options="header",cols="asciidoc,asciidoc",frame="none",valign="middle"] |====================== |XOTcl |Next Scripting Language |[source,tcl] ---------------- Class ClassName ---------------- |[source,tcl] ---------------- Class create ClassName ---------------- |[source,tcl] ---------------- Object ObjectName ---------------- |[source,tcl] ---------------- Object create ObjectName ---------------- |=========================== Defining Methods ~~~~~~~~~~~~~~~~ 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 classes). While the naming in XOTcl tried to follow closely the Tcl tradition (using the term +proc+ for functions/methods), NX uses the term +method+ for defining scripted methods. XOTcl uses the prefix +inst+ to denote that methods are provided for instances, calling therefore scripted methods for instances +instproc+. This is certainly an unusual term. The approach with the name prefix has the disadvantage, that for every different kind of method, two names have to be provided (eg. +proc+ and +instproc+, +forward+ and +instforward+). NX on the contrary uses the same term for defining inherited or 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+ 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 introduces method protection, which is only supported by NX. ==== Scripted Methods Defined in the Init-block of a Class/Object or with Separate Calls 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). [options="header",cols="asciidoc,asciidoc",frame="none",valign="middle"] |====================== |XOTcl |Next Scripting Language |[source,tcl] ---------------- # Define method 'foo' and class # method 'bar' for a Class 'C' with separate # toplevel commands Class C C instproc foo args {...} C proc bar args {...} ---------------- |[source,tcl] ---------------- # Define method and class method # in the init-block of a class Class create C { :method foo args {...} :class method bar args {...} } ---------------- [source,tcl] ---------------- # Define method and class method # with separate commands Class create C C method foo args {...} C class method bar args {...} ---------------- |[source,tcl] ---------------- # Define object-specific method foo # for an object 'o' with separate commands Object o o set x 1 o proc foo args {...} ---------------- |[source,tcl] ---------------- # Define class method and set # instance variable in the init-block of # an object Object create o { set :x 1 :method foo args {...} } ---------------- [source,tcl] ---------------- # Define class method and set # instance variable with separate # commands Object create o o eval {set :x 1} o method foo args {...} ---------------- |=========================== ==== Different Kinds of Methods 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. [options="header",cols="asciidoc,asciidoc",frame="none",valign="middle"] |====================== |XOTcl |Next Scripting Language |[source,tcl] ---------------- # Methods for defining methods: # # proc # instproc # forward # instforward # parametercmd # instparametercmd # # All these methods return empty. ---------------- |[source,tcl] ---------------- # Methods for defining methods: # # method # forward # alias # attribute # # All these methods return method-handles. ---------------- |=========================== In addition to scripted methods (previous section) XOTcl supports forwarder (called +forward+ and +instforward+) and accessor functions to variables (called +parametercmd+ and +instparametercmd+). The accessor functions are used normally internally when object-specific parameters are defined (see Section 3.4). 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::method::setter+ for it. [options="header",cols="asciidoc,asciidoc",frame="none",valign="middle"] |====================== |XOTcl |Next Scripting Language |[source,tcl] ---------------- Class C C instforward f1 ... C forward f2 ... Object o o forward f3 ... ---------------- |[source,tcl] ---------------- # Define forwarder Class create C { :forward f1 ... :class forward f2 ... } Object create o { :forward f3 ... } ---------------- |[source,tcl] ---------------- # Define setter and getter methods in XOTcl. # # XOTcl provides methods for these. Class C C instparametercmd p1 C parametercmd p2 Object o o parametercmd p3 ---------------- |[source,tcl] ---------------- # 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::method::setter C p1 ::nsf::method::setter C -per-object p2 Object create o ::nsf::method::setter o p3 ---------------- |====================== NX supports in contrary to XOTcl the method +alias+ which can be used to register arbitrary Tcl commands or methods for an object or class under a provided method name. Aliases can be used to reuse a certain implementation in e.g. different object systems under potentially different names. In some respects aliases are similar to forwarders, but they do not involve forwarding overhead. [options="header",cols="asciidoc,asciidoc",frame="none",valign="middle"] |====================== |XOTcl |Next Scripting Language |[source,tcl] ---------------- # Method "alias" not available ---------------- |[source,tcl] ---------------- # Define method aliases # (to scripted or non-scripted methods) Class create C { :alias a1 ... :class alias a2 ... } Object create o { :alias a3 ... } ---------------- |=========================== [[method-protect-example]] ==== Method Modifiers and Method Protection 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 class-specific methods (see above). The concept of method protection is new in NX. [options="header",cols="asciidoc,asciidoc",frame="none",valign="middle"] |====================== |XOTcl |Next Scripting Language |[source,tcl] ---------------- # Method modifiers # # "class", # "public", and # "protected" # # are not available ---------------- |[source,tcl] ---------------- # Method modifiers # # "class", # "public", and # "protected" # # are applicable for all kinds of method # defining methods: # # method, forward, alias, attribute Class create C { :/method-definiton-method/ ... :public /method-definiton-method/ ... :protected /method-definiton-method/ ... :class /method-definiton-method/ ... :protected class /method-definiton-method/ ... :public class /method-definiton-method/ ... } ---------------- |====================== XOTcl does not provide method protection. In NX, all methods are defined per default as protected. These defaults 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 defaultAttributeCallProtection true|false` can set the default protection for attributes. The defaults can be overwritten also e.g. on a class level. === Resolvers 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 names starting with a colon `:` specially. In short, a colon-prefixed variable name refers to an instance variable, and a colon-prefixed function name refers to a method. The sub-sections below provide detailed examples. Note that the resolvers of the Next Scripting Framework can be used in the XOTcl 2.* environment as well. ==== Invoking Methods 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 single colon. The invocation of the methods of other objects is the same in NX and XOTcl. [options="header",cols="asciidoc,asciidoc",frame="none",valign="middle"] |====================== |XOTcl |Next Scripting Language |[source,tcl] ---------------- Class C C instproc foo args {...} C instproc bar args { my foo 1 2 3 ;# invoke own method o baz ;# invoke other objects method } Object o o proc baz {} {...} ---------------- |[source,tcl] ---------------- Class create C { :method foo args {...} :method bar args { :foo 1 2 3 ;# invoke own method o baz ;# invoke other objects method } } Object create o { :public method baz {} {...} } ---------------- |====================== ==== Accessing Own Instance Variables from Method Bodies 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 the own instance variables. On the contrary, in XOTcl, the variable access to own and other variables are fully symmetric. In XOTcl, the following approaches are used to access instance variables: - Import instance variables via +instvar+ and access variables via +$varName+ - 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?+ In NX, the favored approach to access instance variables is to use the name resolvers, although it is as well possible to import variables via +nx::var import+ or to check for the existence of instance variables via +nx::var exists+. The following examples summary the use cases for accessing the own and other instance variables. [options="header",cols="asciidoc,asciidoc",frame="none",valign="middle"] |====================== |XOTcl |Next Scripting Language |[source,tcl] ---------------- Class C C instproc foo args { # Method scoped variable a set a 1 # Instance variable b my instvar b set b 2 # Global variable/namespaced variable c set ::c 3 } ---------------- |[source,tcl] ---------------- Class create C { :method foo args {...} # Method scoped variable a set a 1 # Instance variable b set :b 2 # Global variable/namespaced variable c set ::c 3 } } ---------------- |[source,tcl] ---------------- ... instproc ... { my set /varName/ ?value? } ---------------- |[source,tcl] ---------------- # Set own instance variable to a value via # resolver (preferred and fastest way) ... method ... { set /:newVar/ ?value? } ---------------- |[source,tcl] ---------------- ... instproc ... { my instvar /varName/ set /varName/ ?value? } ---------------- |[source,tcl] ---------------- # Set own instance variable via # variable import ... method ... { ::nx::var import [self] /varName/ set /varName/ ?value? } ---------------- |[source,tcl] ---------------- ... instproc ... { set /varName/ [my set /otherVar/] } ---------------- |[source,tcl] ---------------- # Read own instance variable ... method ... { set /varName/ [set /:otherVar/] } ---------------- [source,tcl] ---------------- ... method ... { set /newVar/ ${/:otherVar/} } ---------------- |[source,tcl] ---------------- ... instproc ... { my exists /varName/ } ---------------- |[source,tcl] ---------------- # Test existence of own instance variable ... method ... { info /:varName/ } ---------------- [source,tcl] ---------------- ... method ... { ::nx::var exists [self] /varName/ } ---------------- |====================== ==== Accessing Instance Variables of other Objects [options="header",cols="asciidoc,asciidoc",frame="none",valign="middle"] |====================== |XOTcl |Next Scripting Language |[source,tcl] ---------------- /obj/ set /varName/ ?value? ---------------- |[source,tcl] ---------------- # Set instance variable of object obj to a # value via resolver # (preferred way: define attribute on obj) /obj/ eval [list set /:varName/ ?value?] ---------------- |[source,tcl] ---------------- set /varName/ [/obj/ set /otherVar/] ---------------- |[source,tcl] ---------------- # Read instance variable of object obj # via resolver set /varName/ [/obj/ eval {set /:otherVar/}] ---------------- |[source,tcl] ---------------- ... instproc ... { /obj/ instvar /varName/ set /varName/ ?value? } ---------------- |[source,tcl] ---------------- # Read instance variable of object /obj/ # via import ... method ... { ::nx::var import /obj/ /varName/ set /varName/ ?value? } ---------------- |[source,tcl] ---------------- /obj/ exists varName ---------------- |[source,tcl] ---------------- # Test existence of instance variable of # object obj /obj/ eval {info exists /:varName/} ---------------- [source,tcl] ---------------- ::nx::var exists /obj/ /varName/ ---------------- |====================== === 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. Furthermore, the Next Scripting Framework provides - unified parameter checking (for object and method parameters) and - return value checking based on the same mechanisms. ==== Object Parameters 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+. [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" Class Foo -parameter {a {b 1}} # Create instance of the class Foo Foo f1 -a 0 # Object f1 has 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}} # Create instance of the class Foo Foo create f1 -a 0 # Object f1 has 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. 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 object (usable via a non-positional parameter during object creation), and . register an accessor function (setter), for wich the usual protection levels (+public+ or +protected+) can be used. [options="header",cols="asciidoc,asciidoc",frame="none",valign="middle"] |====================== |XOTcl |Next Scripting Language |[source,tcl] ---------------- # Object parameter specified via slots Class Foo -slots { Attribute a Attribute b -default 1 } # Create instance of the class Foo Foo f1 -a 0 # Object f1 has a == 0 and b == 1 ---------------- |[source,tcl] ---------------- # Object parameter specified via attribute # methods (supports method modifiers and # scripted configuration) Class create Foo { :attribute a :attribute {b 1} } # Create instance of the class Foo Foo create f1 -a 0 # Object f1 has a == 0 and b == 1 ---------------- |[source,tcl] ---------------- # Parameters only available at class level ---------------- |[source,tcl] ---------------- # Define object parameter at the class # and object level Class create C { :attribute x :attribute {y 1} :class attribute oa1 } Object create o { :attribute oa2 } ---------------- |[source,tcl] ---------------- # Object parameter with configured slot, # defining an attribute specific type # checker Class Person -slots { Attribute create sex -type "sex" { my proc type=sex {name value} { switch -glob $value { m* {return m} f* {return f} default { error "expected sex but got $value" } } } } } ---------------- |[source,tcl] ---------------- # Object parameter with scripted # definition (init-block), defining an # attribute specific type checker Class create Person { :attribute sex { :type "sex" :method type=sex {name value} { switch -glob $value { m* {return m} f* {return f} default { error "expected sex but got $value" } } } } } ---------------- |====================== XOTcl 1 did not support value constraints for object parameters (just for non-positional arguments). 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 performance sensitive. [options="header",cols="asciidoc,asciidoc",frame="none",valign="middle"] |====================== |XOTcl |Next Scripting Language |[source,tcl] ---------------- # Value constraints for parameter # not available ---------------- |[source,tcl] ---------------- # Predefined value constraints: # object, class, alnum, alpha, ascii, boolean, # 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. Class create Foo -attributes { a:boolean {b:integer 1} } ---------------- [source,tcl] ---------------- Class create Foo { :attribute a:boolean :attribute {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. [options="header",cols="asciidoc,asciidoc",frame="none",valign="middle"] |====================== |XOTcl |Next Scripting Language |[source,tcl] ---------------- # Required parameter not available ---------------- |[source,tcl] ---------------- # Required parameter: # Define a required attribute "a" and a # required boolean attribute "b" Class create Foo -attributes { a:required b:boolean,required } ---------------- [source,tcl] ---------------- Class create Foo { :attribute a:required :attribute b:boolean,required } ---------------- |====================== NX supports in contrary to XOTcl to define the _multiplicity_ of values per parameter. In NX, one can specify that a parameter can accept the value "" (empty) in addition to e.g. an integer, or one can specify that the value is an empty or non-empty ist of values via the multiplicity. For every specified value, the value checkers are applied. [options="header",cols="asciidoc,asciidoc",frame="none",valign="middle"] |====================== |XOTcl |Next Scripting Language |[source,tcl] --------------- # Multiplicity for parameter not available ----------------- |[source,tcl] ---------------- # Parameter with multiplicity 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 } ---------------- [source,tcl] ---------------- Class create Foo { :attribute {ints:integer,0..n ""} :attribute objs:object,1..n :attribute obj:object,0..1 } ---------------- |====================== ==== Method Parameters 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 positional arguments, this limitation is lifted in XOTcl 2. [options="header",cols="asciidoc,asciidoc",frame="none",valign="middle"] |====================== |XOTcl |Next Scripting Language |[source,tcl] ---------------- # Define method foo with non-positional # parameters (x, y and y) and positional # parameter (a and b) Class C C instproc foo {-x:integer -y:required -z a b} { # ... } C create c1 # invoke method foo c1 foo -x 1 -y a 2 3 ---------------- |[source,tcl] ---------------- # Define method foo with non-positional # parameters (x, y and y) and positional # parameter (a and b) Class create C { :public method foo {-x:integer -y:required -z a b} { # ... } :create c1 } # invoke method foo c1 foo -x 1 -y a 2 3 ---------------- |[source,tcl] ---------------- # Only leading non-positional parameters # are available; no optional positional # parameters, no value constraints on # positional parameters, no multiplicity, ... ---------------- |[source,tcl] ---------------- # Define various forms of parameters # not available in XOTcl 1 Class create C { # trailing (or interleaved) non-positional # parameters :public method m1 {a b -x:integer -y} { # ... } # 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 # available (see above). # # User defined value constraints are # possible. All parameter value checkers # can be turned on and off. } ---------------- |====================== ==== 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 checkers, return value checkers can be turned on and off. [options="header",cols="asciidoc,asciidoc",frame="none",valign="middle"] |====================== |XOTcl |Next Scripting Language |[source,tcl] ---------------- # No return value checking available ---------------- |[source,tcl] ---------------- # Define method foo with non-positional # parameters (x, y and y) and positional # parameter (a and b) Class create C { # Define method foo which returns an # integer value :method foo -returns integer {-x:integer} { # ... } # Define an alias for the Tcl command ::incr # and assure, it always returns an integer # value :alias incr -returns integer ::incr # Define a forwarder that has to return an # integer value :forward ++ -returns integer ::expr 1 + # Define a method that has to return a # non-empty list of objects :public class method instances {} \ -returns object,1..n { return [:info instances] } } ---------------- |====================== === Interceptors XOTcl and NX allow the definition of the same set of interceptors, namely class- and object-level mixins and class- and object-level filters. The primary difference in NX is the naming, since NX abandons the prefix "inst" from the method names. Therefore, in NX, if a +mixin+ is registered on the class-level, it is 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+ (in the same way as e.g. for defining methods). ==== Register Mixin Classes and Mixin Guards [options="header",cols="asciidoc,asciidoc",frame="none",valign="middle"] |====================== |XOTcl |Next Scripting Language |[source,tcl] ---------------- /cls/ instmixin ... /cls/ instmixinguard /mixin/ ?condition? ---------------- |[source,tcl] ---------------- # Register per-class mixin and guard for # a class /cls/ mixin ... /cls/ mixin guard /mixin/ ?condition? ---------------- |[source,tcl] ---------------- /cls/ mixin ... /cls/ mixin guard /mixin/ ?condition? ---------------- |[source,tcl] ---------------- # Register per-object mixin and guard for # a class /cls/ class mixin ... /cls/ class mixin guard /mixin/ ?condition? ---------------- |[source,tcl] ---------------- /obj/ mixin ... /obj/ mixinguard /mixin/ ?condition? ---------------- |[source,tcl] ---------------- # Register per-object mixin and guard for # an object /obj/ mixin ... /obj/ mixin guard /mixin/ ?condition? ---------------- |====================== ==== Register Filters and Filter Guards [options="header",cols="asciidoc,asciidoc",frame="none",valign="middle"] |====================== |XOTcl |Next Scripting Language |[source,tcl] ---------------- /cls/ instfilter ... /cls/ instfilterguard /filter/ ?condition? ---------------- |[source,tcl] ---------------- # Register per-class filter and guard for # a class /cls/ filter ... /cls/ filter guard /filter/ ?condition? ---------------- |[source,tcl] ---------------- /cls/ filter ... /cls/ filterguard ... ---------------- |[source,tcl] ---------------- # Register per-object filter and guard for # a class /cls/ class filter ... /cls/ class filter guard /filter/ ?condition? ---------------- |[source,tcl] ---------------- /obj/ filter ... /obj/ filterguard /filter/ ?condition? ---------------- |[source,tcl] ---------------- # Register per-object filter and guard for # an object /obj/ filter ... /obj/ filter guard /filter/ ?condition? ---------------- |====================== === Introspection In general, introspection in NX became more orthogonal and less dependent on the type of the method. In XOTcl it was e.g. necessary that a developer had to know, whether a method is e.g. scripted or not and has to use accordingly different sub-methods of +info+. 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, 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 While XOTcl uses different names for obtaining different kinds of methods defined by a class, NX uses +info methods+ in an orthogonal manner. NX allows as well to use the call protection to filter the returned methods. [options="header",cols="asciidoc,asciidoc",frame="none",valign="middle"] |====================== |XOTcl |Next Scripting Language |[source,tcl] ---------------- /cls/ info instcommands ?pattern? ---------------- |[source,tcl] ---------------- /cls/ info methods ?pattern? ---------------- |[source,tcl] ---------------- /cls/ info instparametercmd ?pattern? ---------------- |[source,tcl] ---------------- /cls/ info methods -methodtype setter ?pattern? ---------------- |[source,tcl] ---------------- /cls/ info instprocs ?pattern? ---------------- |[source,tcl] ---------------- /cls/ info methods -methodtype scripted ?pattern? ---------------- |[source,tcl] ---------------- # n.a. ---------------- |[source,tcl] ---------------- /cls/ info methods -methodtype alias ?pattern? ---------------- |[source,tcl] ---------------- # n.a. ---------------- |[source,tcl] ---------------- /cls/ info methods -methodtype forwarder ?pattern? ---------------- |[source,tcl] ---------------- # n.a. ---------------- |[source,tcl] ---------------- /cls/ info methods -methodtype object ?pattern? ---------------- |[source,tcl] ---------------- # n.a. ---------------- |[source,tcl] ---------------- /cls/ info methods -callprotection public\|protected ... ---------------- |====================== ==== List methods defined by objects While XOTcl uses different names for obtaining different kinds of methods defined by an object, NX uses +info methods+ in an orthogonal manner. NX allows as well to use the call protection to filter the returned methods. [options="header",cols="asciidoc,asciidoc",frame="none",valign="middle"] |====================== |XOTcl |Next Scripting Language |[source,tcl] ---------------- /obj/ info commands ?pattern? ---------------- |[source,tcl] ---------------- /obj/ info methods ?pattern? ---------------- |[source,tcl] ---------------- /obj/ info parametercmd ?pattern? ---------------- |[source,tcl] ---------------- /obj/ info methods -methodtype setter ?pattern? ---------------- |[source,tcl] ---------------- /obj/ info procs ?pattern? ---------------- |[source,tcl] ---------------- /obj/ info methods -methodtype scripted ?pattern? ---------------- |[source,tcl] ---------------- # n.a. ---------------- |[source,tcl] ---------------- /obj/ info methods -methodtype alias ?pattern? ---------------- |[source,tcl] ---------------- # n.a. ---------------- |[source,tcl] ---------------- /obj/ info methods -methodtype forwarder ?pattern? ---------------- |[source,tcl] ---------------- # n.a. ---------------- |[source,tcl] ---------------- /obj/ info methods -methodtype object ?pattern? ---------------- |[source,tcl] ---------------- # n.a. ---------------- |[source,tcl] ---------------- /obj/ info methods -callprotection public\|protected ... ---------------- |====================== ==== List class object specific 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"] |====================== |XOTcl |Next Scripting Language |[source,tcl] ---------------- /cls/ info commands ?pattern? ---------------- |[source,tcl] ---------------- /cls/ class info methods ?pattern? ---------------- |[source,tcl] ---------------- /cls/ info parametercmd ?pattern? ---------------- |[source,tcl] ---------------- /cls/ class info methods -methodtype setter ?pattern? ---------------- |[source,tcl] ---------------- /cls/ info procs ?pattern? ---------------- |[source,tcl] ---------------- /cls/ class info methods -methodtype scripted ?pattern? ---------------- |[source,tcl] ---------------- # n.a. ---------------- |[source,tcl] ---------------- /cls/ class info methods -methodtype alias ?pattern? ---------------- |[source,tcl] ---------------- # n.a. ---------------- |[source,tcl] ---------------- /cls/ class info methods -methodtype forwarder ?pattern? ---------------- |[source,tcl] ---------------- # n.a. ---------------- |[source,tcl] ---------------- /cls/ class info methods -methodtype object ?pattern? ---------------- |[source,tcl] ---------------- # n.a. ---------------- |[source,tcl] ---------------- /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 class hierarchy, NX uses +info lookup+. One can either lookup methods (via +info lookup methods+) or slots (via +info lookup slots+). The plural term refers to a potential set of return values. [options="header",cols="asciidoc,asciidoc",frame="none",valign="middle"] |====================== |XOTcl |Next Scripting Language |[source,tcl] ---------------- /obj/ info methods ?pattern? ---------------- |[source,tcl] ---------------- /obj/ info lookup methods ... ?pattern? # Returns list of method names ---------------- |[source,tcl] ---------------- # n.a. ---------------- |[source,tcl] ---------------- # List only application specific methods /obj/ info lookup methods -source application ... ?pattern? # Returns list of method names ---------------- |[source,tcl] ---------------- # Options for 'info methods' # # -incontext # -nomixins ---------------- |[source,tcl] ---------------- # Options for 'info lookup methods' # # -source ... # -callprotection ... # -incontext # -methodtype ... # -nomixins ---------------- |[source,tcl] ---------------- # n.a. ---------------- |[source,tcl] ---------------- # List slot objects defined for obj /obj/ info lookup slots ?-type /type/? # Returns list of slot objects of specified type (class) ---------------- |====================== ==== List object/class where some 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 a method or filter is defined. The concept of a _method-handle_ is new in NX. The method-handle can be used to obtain more information about the method, such as e.g. the definition of the method. [options="header",cols="asciidoc,asciidoc",frame="none",valign="middle"] |====================== |XOTcl |Next Scripting Language |[source,tcl] ---------------- /obj/ procsearch /methodName/ ---------------- |[source,tcl] ---------------- /obj/ info lookup method /methodName/ # Returns method-handle ---------------- |[source,tcl] ---------------- /obj/ filtersearch /methodName/ ---------------- |[source,tcl] --------------- /obj/ info lookup filter /methodName/ # Returns method-handle ----------------- |====================== ==== List definition of scripted methods defined by classes XOTcl contains a long list of +info+ subcommands for different kinds of methods and for obtaining more detailed information about these methods. In NX, this list of +info+ subcommands is much shorter and more orthogonal. For example +info method definition+ can be used to obtain with a single command the full definition of a _scripted method_, and furthermore, it works as well the same way to obtain e.g. the definition of a _forwarder_ or an _alias_. Another powerful introspection option in NX is +info method parametersyntax+ which obtains a representation of the parameters of a method in the style of Tcl man pages (regardless of the kind of method). [options="header",cols="asciidoc,asciidoc",frame="none",valign="middle"] |====================== |XOTcl |Next Scripting Language |[source,tcl] ---------------- # n.a. ---------------- |[source,tcl] ---------------- /cls/ info method definition /methodName/ ---------------- |[source,tcl] ---------------- /cls/ info instbody /methodName/ ---------------- |[source,tcl] ---------------- /cls/ info method body /methodName/ ---------------- |[source,tcl] ---------------- /cls/ info instargs /methodName/ ---------------- |[source,tcl] ---------------- /cls/ info method args /methodName/ ---------------- |[source,tcl] ---------------- /cls/ info instnonposargs /methodName/ ---------------- |[source,tcl] ---------------- /cls/ info method parameter /methodName/ ---------------- |[source,tcl] ---------------- /cls/ info instdefault /methodName/ ---------------- |[source,tcl] ---------------- # not needed, part of "info method parameter" ---------------- |[source,tcl] ---------------- /cls/ info instpre /methodName/ ---------------- |[source,tcl] ---------------- /cls/ info method precondition /methodName/ ---------------- |[source,tcl] ---------------- /cls/ info instpost /methodName/ ---------------- |[source,tcl] ---------------- /cls/ info method postcondition /methodName/ ---------------- |[source,tcl] ---------------- # n.a. ---------------- |[source,tcl] ---------------- /cls/ info method parametersyntax /methodName/ ---------------- |====================== ==== List definition of scripted object specific methods While XOTcl uses different names for info options for objects and classes (using the prefix "inst"), the names in NX are the same. [options="header",cols="asciidoc,asciidoc",frame="none",valign="middle"] |====================== |XOTcl |Next Scripting Language |[source,tcl] ---------------- # n.a. ---------------- |[source,tcl] ---------------- /obj/ info method definition /methodName/ ---------------- |[source,tcl] ---------------- /obj/ info body /methodName/ ---------------- |[source,tcl] ---------------- /obj/ info method body /methodName/ ---------------- |[source,tcl] ---------------- /obj/ info args /methodName/ ---------------- |[source,tcl] ---------------- /obj/ info method args /methodName/ ---------------- |[source,tcl] ---------------- /obj/ info nonposargs /methodName/ ---------------- |[source,tcl] ---------------- /obj/ info method parameter /methodName/ ---------------- |[source,tcl] --------------- /obj/ info default /methodName/ ----------------- |[source,tcl] ---------------- # not needed, part of "info method parameter" ---------------- |[source,tcl] ---------------- /obj/ info pre /methodName/ ---------------- |[source,tcl] ---------------- /obj/ info method precondition /methodName/ ---------------- |[source,tcl] ---------------- /obj/ info post /methodName/ ---------------- |[source,tcl] ---------------- /obj/ info method postcondition /methodName/ ---------------- |[source,tcl] ---------------- # n.a. ---------------- |[source,tcl] ---------------- /obj/ info method parametersyntax /methodName/ ---------------- |====================== For definition of class object specific methods, use the modifier +class+ as shown in examples above. ==== List Filter or Mixins In NX all introspection options for filters are grouped under +info filter+ and all introspection options for mixins are under +info mixin+. Therefore, NX follows here the approach of using hierarchical subcommands rather than using a flat namespace. [options="header",cols="asciidoc,asciidoc",frame="none",valign="middle"] |====================== |XOTcl |Next Scripting Language |[source,tcl] ---------------- /obj/ info filter ?-guards? ?-order? ?pattern? ---------------- |[source,tcl] ---------------- # ... info filter methods -order ... returns # method-handles instead of triples # (applies to all three variants) /obj/ info filter methods \ ?-guards? ?-order? ?pattern? ---------------- |[source,tcl] ---------------- /obj/ info filterguard /name/ ---------------- |[source,tcl] ---------------- /obj/ info filter guard /name/ ---------------- |[source,tcl] ---------------- /cls/ info filter ?-guards? ?-order? ?pattern? ---------------- |[source,tcl] ---------------- /cls/ class info filter methods \ ?-guards? ?-order? ?pattern? ---------------- |[source,tcl] ---------------- /cls/ info filterguard /name/ ---------------- |[source,tcl] ---------------- /cls/ class info filter guard /name/ ---------------- |[source,tcl] ---------------- /cls/ info instfilter \ ?-guards? ?-order? ?pattern? ---------------- |[source,tcl] ---------------- /cls/ info filter methods \ ?-guards? ?-order? ?pattern? ---------------- |[source,tcl] ---------------- /cls/ info instfilterguard /name/ ---------------- |[source,tcl] ---------------- /cls/ info filter guard /name/ ---------------- |[source,tcl] ---------------- /obj/ info mixin ?-guards? ?-order? ?pattern? ---------------- |[source,tcl] ---------------- /obj/ info mixin classes \ ?-guards? ?-order? ?pattern? ---------------- |[source,tcl] ---------------- /obj/ info mixinguard /name/ ---------------- |[source,tcl] ---------------- /obj/ info mixin guard /name/ ---------------- |[source,tcl] ---------------- /cls/ info mixin ?-guards? ?-order? ?pattern? ---------------- |[source,tcl] ---------------- /cls/ class info mixin classes \ ?-guards? ?-order? ?pattern? ---------------- |[source,tcl] ---------------- /cls/ info mixinguard /name/ ---------------- |[source,tcl] ---------------- /cls/ class info mixin guard /name/ ---------------- |[source,tcl] ---------------- /cls/ info instmixin \ ?-guards? ?-order? ?pattern? ---------------- |[source,tcl] ---------------- /cls/ info mixin classes \ ?-guards? ?-order? ?pattern? ---------------- |[source,tcl] ---------------- /cls/ info instmixinguard /name/ ---------------- |[source,tcl] ---------------- /cls/ info mixin guard /name/ ---------------- |====================== ==== List definition of methods defined by aliases, setters or forwarders As mentioned earlier, +info method definition+ can be used on every kind of method. [options="header",cols="asciidoc,asciidoc",frame="none",valign="middle"] |====================== |XOTcl |Next Scripting Language |[source,tcl] ---------------- # n.a. ---------------- |[source,tcl] ---------------- /obj/ 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 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. [options="header",cols="asciidoc,asciidoc",frame="none",valign="middle"] |====================== |XOTcl |Next Scripting Language |[source,tcl] ---------------- # n.a. ---------------- |[source,tcl] ---------------- /obj/ info method handle /methodName/ ---------------- |[source,tcl] ---------------- # n.a. ---------------- |[source,tcl] ---------------- /cls/ ?class? info method handle /methodName/ ---------------- |====================== ==== List type of a method The method +info method type+ is new in NX to obtain the type of the specified method. [options="header",cols="asciidoc,asciidoc",frame="none",valign="middle"] |====================== |XOTcl |Next Scripting Language |[source,tcl] ---------------- # n.a. ---------------- |[source,tcl] ---------------- /obj/ info method type /methodName/ ---------------- |[source,tcl] ---------------- # n.a. ---------------- |[source,tcl] ---------------- /cls/ ?class? info method type /methodName/ ---------------- |====================== ==== List the scope of mixin classes NX provides a richer set of introspection options to obtain information, where mixins classes are mixed into. [options="header",cols="asciidoc,asciidoc",frame="none",valign="middle"] |====================== |XOTcl |Next Scripting Language |[source,tcl] ---------------- /cls/ info mixinof ?-closure? ?pattern? ---------------- |[source,tcl] ---------------- # List objects, where /cls/ is a # per-object mixin /cls/ info mixinof -scope object ?-closure? ?pattern? ---------------- |[source,tcl] ---------------- /cls/ info instmixinof ?-closure? ?pattern? ---------------- |[source,tcl] ---------------- # List classes, where /cls/ is a per-class mixin /cls/ info mixinof -scope class ?-closure? ?pattern? ---------------- |[source,tcl] ---------------- # n.a. ---------------- |[source,tcl] ---------------- # List objects and classes, where /cls/ is # either a per-object or a per-class mixin /cls/ info mixinof -scope all ?-closure? ?pattern? ---------------- [source,tcl] ---------------- /cls/ info mixinof ?-closure? ?pattern? ---------------- |====================== ==== Check properties of object and classes Similar as noted before, NX uses rather a hierarchical approach of naming using multiple layers of subcommands). [options="header",cols="asciidoc,asciidoc",frame="none",valign="middle"] |====================== |XOTcl |Next Scripting Language |[source,tcl] ---------------- /obj/ istype /sometype/ ---------------- |[source,tcl] ---------------- /obj/ info has type /sometype/ ---------------- |[source,tcl] ---------------- /obj/ ismixin /cls/ ---------------- |[source,tcl] ---------------- /obj/ info has mixin /cls/ ---------------- |[source,tcl] ---------------- /obj/ isclass ?/cls/? ---------------- |[source,tcl] ---------------- /obj/ info is class ---------------- |[source,tcl] ---------------- /obj/ ismetaclass /cls/ ---------------- |[source,tcl] ---------------- /obj/ info is metaclass ---------------- |[source,tcl] ---------------- # n.a. ---------------- |[source,tcl] ---------------- /obj/ info is baseclass ---------------- |[source,tcl] ---------------- /obj/ object::exists /obj/ ---------------- |[source,tcl] ---------------- ::nsf::object::exists /obj/ ---------------- |====================== ==== Call-stack Introspection Call-stack introspection is very similar in NX and XOTcl. NX uses for subcommand the term +current+ instead of +self+, since +self+ has a strong connotation to the current object. The term +proc+ is renamed by +method+. [options="header",cols="asciidoc,asciidoc",frame="none",valign="middle"] |====================== |XOTcl |Next Scripting Language |[source,tcl] ---------------- self ---------------- |[source,tcl] ---------------- self ---------------- [source,tcl] ---------------- current object ---------------- |[source,tcl] ---------------- self class ---------------- |[source,tcl] ---------------- current class ---------------- |[source,tcl] ---------------- self proc ---------------- |[source,tcl] ---------------- current method ---------------- |[source,tcl] ---------------- self callingclass ---------------- |[source,tcl] ---------------- current currentclass ---------------- |[source,tcl] ---------------- self callingobject ---------------- |[source,tcl] ---------------- current callingobject ---------------- |[source,tcl] ---------------- self callingproc ---------------- |[source,tcl] ---------------- current callingmethod ---------------- |[source,tcl] ---------------- self calledclass ---------------- |[source,tcl] ---------------- current calledclass ---------------- |[source,tcl] ---------------- self calledproc ---------------- |[source,tcl] ---------------- current calledmethod ---------------- |[source,tcl] ---------------- self isnextcall ---------------- |[source,tcl] ---------------- current isnextcall ---------------- |[source,tcl] ---------------- self next ---------------- |[source,tcl] ---------------- # Returns method-handle current next ---------------- |[source,tcl] ---------------- self filterreg ---------------- |[source,tcl] ---------------- # Returns method-handle current filterreg ---------------- |[source,tcl] ---------------- self callinglevel ---------------- |[source,tcl] ---------------- current callinglevel ---------------- |[source,tcl] ---------------- self activelevel ---------------- |[source,tcl] ---------------- current activelevel ---------------- |====================== === Other Predefined Methods [options="header",cols="asciidoc,asciidoc",frame="none",valign="middle"] |====================== |XOTcl |Next Scripting Language |[source,tcl] ---------------- /obj/ requireNamespace ---------------- |[source,tcl] ---------------- /obj/ require namespace ---------------- |[source,tcl] ---------------- # n.a. ---------------- |[source,tcl] ---------------- /obj/ require method ---------------- |====================== === Dispatch, Aliases, etc. todo: to be done or omitted === Assertions 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::method::assertion+. [options="header",cols="asciidoc,asciidoc",frame="none",valign="middle"] |====================== |XOTcl |Next Scripting Language |[source,tcl] ---------------- /obj/ check /checkoptions/ ---------------- |[source,tcl] ---------------- ::nsf::method::assertion /obj/ check /checkptions/ ---------------- |[source,tcl] ---------------- /obj/ info check ---------------- |[source,tcl] ---------------- ::nsf::method::assertion /obj/ check ---------------- |[source,tcl] ---------------- /obj/ invar /conditions/ ---------------- |[source,tcl] ---------------- ::nsf::method::assertion /obj/ object-invar /conditions/ ---------------- |[source,tcl] ---------------- /obj/ info invar ---------------- |[source,tcl] ---------------- ::nsf::method::assertion /obj/ object-invar ---------------- |[source,tcl] ---------------- /cls/ instinvar /conditions/ ---------------- |[source,tcl] ---------------- ::nsf::method::assertion /cls/ class-invar /conditions/ ---------------- |[source,tcl] ---------------- /cls/ info instinvar ---------------- |[source,tcl] ---------------- ::nsf::method::assertion /cls/ class-invar ---------------- |[source,tcl] ---------------- /cls/ invar /conditions/ ---------------- |[source,tcl] ---------------- ::nsf::method::assertion /cls/ object-invar /conditions/ ---------------- |[source,tcl] ---------------- /cls/ info invar ---------------- |[source,tcl] ---------------- ::nsf::method::assertion /cls/ object-invar ---------------- |====================== === Method Protection As described <>, NX supports method protection via the method modifiers `protected` and `public`. A 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, the most specific definition (might be a mixin) is used for determining the protection. == Incompatibilities between XOTcl 1 and XOTcl 2 === Resolvers The resolvers (variable resolvers, function resolvers) of the Next Scripting Framework are used as well within XOTcl 2. When variable names or method names starting with a single colon are used in XOTcl 1 scripts, conflicts will arise with the resolver. These names must be replaced. === Parameters The following changes for parameters could be regarded as bug-fixes. ==== Parameter usage without a value In XOTcl 1, it was possible to call a parameter method during object 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 ---------------- Such cases are most likely mistakes. All parameter configurations in XOTcl 2 require an argument. ==== Ignored Parameter definitions In XOTcl 1, a more specific parameter definition without a default was ignored when a more general parameter definition with a default was present. In the example below, the object `b1` contained in XOTcl 1 incorrectly the parameter `x` (set via default from `Foo`), while in 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 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 nx::Class create Foo Foo create f1 # now alter the class of object f1 f1 configure -class nx::Object # alternate approach via Next Scripting Framework ::nsf::relation f1 class ::nx::Object ---------------- === Calling Objects via Method Interface 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: [source,tcl] ---------------- # XOTcl example 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. === 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. === Obsolete Commands Parameter-classes were rarely used and have been replaced by the more general object parameterization. Therefore, `cl info parameterclass` has 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. === Exit Handlers The exit hander interface changed from a method of `::xotcl::Object` into the Tcl command `::nsf::exithandler`: [source,tcl] ---------------- # NX example ::nsf::exithandler set|get|unset ?arg? ----------------