The Next Scripting Language (NX) is a highly flexible, Tcl [Ousterhout 1990] based object oriented scripting language. It is a successor of XOTcl 1 [Neumann and Zdun 2000a] 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.
1. NX and its Roots
Object oriented extensions of Tcl have quite a long history. Two of the most prominent early Tcl based OO languages were incr Tcl (abbreviated as itcl) and Object Tcl (OTcl [Wetherall and Lindblad 1995]). While itcl provides a traditional C++/Java-like object system, OTcl was following the CLOS approach and supports a dynamic object system, allowing incremental class and object extensions and re-classing of objects.
Extended Object Tcl (abbreviated as XOTcl [Neumann and Zdun 2000a]) is a successor of OTcl and was the first language providing language support for design patterns. XOTcl extends OTcl by providing namespace support, adding assertions, dynamic object aggregations, slots and by introducing per-object and per-class filters and per-object and per-class mixins.
XOTcl was so far released in more than 30 versions. It is described in its detail in more than 20 papers and serves as a basis for other object systems like TclOO [Donal ???]. The scripting language NX and the Next Scripting Framework [Neumann and Sobernig 2009] extend the basic ideas of XOTcl by providing support for language-oriented programming. The 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 can follow different naming conventions for built-in methods. Currently, the Next Scripting Framework is packaged with three object systems: NX, XOTcl 2.0, and TclCool (the language introduced by TIP#279).
The primary purpose of this document is to introduce NX to beginners. We expect some prior knowledge of programming languages, and some knowledge about Tcl. In the following sections we introduce NX by examples. In later sections we introduce the more advanced concepts of the language. Conceptually, most of the addressed concepts are very similar in XOTcl. Concerning the differences between NX and XOTcl, please refer to the "Migration Guide for the Next Scripting Language".
2. Introductory Overview Example: Stack
A classical programming example is an implementation of a stack, which is most likely familiar to many readers from many introductory programming courses. A stack is a last-in first-out data structure which is manipulated via operations like push (add something to the stack) and pop remove an entry from the stack. These operations are called methods in the context of object oriented programming systems. Primary goals of object orientation are encapsulation and abstraction. Therefore, we define a common unit (a class) that defines and encapsulates the behavior of a stack and provides methods to a user of the data structure that abstract from the actual implementation.
2.1. Define a Class "Stack"
In our first example, we define a class named Stack with the methods push and pop. When an instance of the stack is created (e.g. a concrete stack s1) the stack will contain an instance variable named things initialized with the an empty list.
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 | nx::Class create Stack { # # Stack of Things # :variable 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 } } |
Typically, classes are defined in NX via nx::Class create followed by the name of the new class (here: Stack). The definition of the stack placed between curly braces and contains here just the method definitions. Methods of the class are defined via :method followed by the name of the method, an argument list and the body of the method, consisting of Tcl and NX statements.
When an instance of Stack is created, it will contain an instance variable named things. If several Stack instances are created, each of the instances will have their own (same-named but different) instance variable. The instance variable things is used in our example as a list for the internal representation of the stack. We define in a next step the methods to access and modify this list structure. A user of the stack using the the provided methods does not have to have any knowledge about the name or the structure of the internal representation (the instance variable things).
The method push receives an argument thing which should be placed on the stack. Note that we do not have to specify the type of the element on the stack, so we can push strings as well as numbers or other kind of things. When an element is pushed, we add this element as the first element to the list things. We insert the element using the Tcl command linsert which receives the list as first element, the position where the element should be added as second and the new element as third argument. To access the value of the instance variable we use Tcl’s the dollar operator followed by the name. The names of instance variables are preceded with a colon :. Since the name contains a non-plain character, Tcl requires us to put braces around the name. The command linsert and its arguments are placed between square brackets. This means that the function is called and returns the new list, where the new element is inserted at the first position (index 0) in the list things. The result of the linsert function is assigned again to the instance variable things which is updated this way. Finally the method push returns the pushed thing using the return statement.
The method pop returns the most recently stacked element and removes it from the stack. Therefore, it takes the first element from the list (using the Tcl command lindex), assigns it to the method-scoped variable top, removes the element from the instance variable things (by using the Tcl command lrange) and returns the value popped element top.
This finishes our first implementation of the the stack, more enhanced versions will follow. Note that the methods push and pop are defined as public; this means that these methods can be used from all other objects in the system. Therefore, these methods provide an interface to the stack implementation.
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 | #!/bin/env tclsh package require nx nx::Class create Stack { # # Stack of Things # .... } Stack create s1 s1 push a s1 push b s1 push c puts [s1 pop] puts [s1 pop] s1 destroy |
Now we want to use the stack. The code snipped in Listing 3 shows how to use the class Stack in a script. Since NX is based on Tcl, the script will be called with the Tcl shell tclsh. In the Tcl shell we have to require package nx to use the Next Scripting Framework and NX. The next lines contain the definition of the stack as presented before. Of course, it is as well possible to make the definition of the stack an own package, such we could simple say package require stack, or to save the definition of a stack simply in a file and load it via source.
In line 12 we create an instance of the stack, namely the stack object s1. The object s1 has as an instance of the stack access to the methods, which can be invoked by the name of the object followed by the method name. In lines 13-15 we push on the stack the values a, then b, and c. In line 16 we output the result of the pop method using the Tcl command puts. We will see on standard output the value+c+ (the last stacked item). The output of the line 17 is the value b (the previously stacked item). Finally, in line 18 we destroy the object. This is not necessary here, but shows the life cycle of an object. In some respects, destroy is the counterpart of create from line 12.
Figure 4 shows the actual class and object structure of the first Stack example. Note that the common root class is nx::Object that contains methods for all objects. Since classes are as well objects in NX, nx::Class is a specialization of nx::Object. nx::Class provides methods for creating objects, such as the method create which is used to create objects (and classes as well).
2.2. Define an Object Named "stack"
The definition of the stack in Listing 2 is following the traditional object oriented approach, found in practically every object oriented programming language: Define a class with some methods, create instances from this class, and use the methods defined in the class in the instances of the class.
In our next example, we introduce generic objects and object specific methods. With NX, we can define generic objects, which are instances of the most generic class nx::Object (sometimes called "common root class"). nx::Object is predefined and contains a minimal set of methods applicable to all NX objects.
In our second example, we will define a generic object named stack and provide methods for this object. The methods defined in our first example were methods provided by a class for objects. Now we defined object specific methods, which are methods applicable only to the object for which they are defined.
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 | nx::Object create stack { :variable 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 } } |
The example in Listing 5 defines the object stack in a very similar way as the class Stack. But the following points are different.
-
First, we use nx::Object instead of nx::Class to denote that we want to create a generic object, not a class.
-
As in the example above, we use :variable to define the instance variable things for this object (the object stack).
The definition for the methods push and pop are the same as before, but this times they are object specify. All methods defined on an object are object-specific. In order to use the stack, we can use directly the object stack in the same way as we have used the object s1 in Listing 3 (e.g. stack push a). this the object stack.
A reader might wonder when to use a class Stack or rather an object stack. A big difference is certainly that one can define easily multiple instances of a class, while the object is actually a singleton. The concept of the object stack is similar to a module providing a certain functionality via a common interface without providing the functionality to create multiple instances. The reuse of methods provided by the class to objects is as well a difference. If the methods of the class are updated, all instances of the class well immediately get the modified behavior. But this does not mean that there is no reuse for the methods of stack possible. NX allows for example to copy objects (similar to prototype based languages) or to reuse methods via e.g. aliases (more about this later).
Note that we use capitalized names for classes and lowercase names for instances. This is not required and a pure convention making it easier to understand scripts without much analysis.
2.3. Implementing Features using Mixin Classes
So far, the definition of the stack methods was pretty minimal. Suppose, we want to define "safe stacks" that protect e.g. against stack under-runs (a stack under-run happens, when more pop than push operations are issued on a stack). Safety checking can be implemented mostly independent from the implementation details of the stack (usage of internal data structures). There are as well different ways of checking the safety. Therefore we say that safety checking is orthogonal to the stack core implementation.
With NX we can define stack-safety as a separate class using methods with the same names as the implementations before, and "mix" this behavior into classes or objects. The implementation of Safety in stack under-runs and to issue error messages, when this happens.
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 | nx::Class create Safety { # # Implement stack safety by defining an additional # instance variable named "count" that keeps track of # the number of stacked elements. The methods of # this class have the same names and argument lists # as the methods of Stack; these methods "shadow" # the methods of class Stack. # :variable count 0 :public method push {thing} { incr :count next } :public method pop {} { if {${:count} == 0} then { error "Stack empty!" } incr :count -1 next } } |
Note that the methods of the class Safety all end with next. This command is a primitive command of NX, that will call the same-named method with the same argument list as the current invocation.
Assume we safe the definition of the class Stack in a file named Stack.tcl and the definition of the class Safety in a file named Safety.tcl in the current directory. When we load the classes Stack and Safety into the same script (see the terminal dialog in e.g. a certain stack s2 as a safe stack, while all other stacks (such as s1) might be still "unsafe". This can be achieved via the option -mixin at the object creation time (see line 9 in option -mixin mixes the class Safety into the new instance s2.
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 | % package require nx 2.0 % source Stack.tcl ::Stack % source Safety.tcl ::Safety % Stack create s1 ::s1 % Stack create s2 -mixin Safety ::s2 % s2 push a a % s2 pop a % s2 pop Stack empty! % s1 info precedence ::Stack ::nx::Object % s2 info precedence ::Safety ::Stack ::nx::Object |
When the method push of s2 is called, first the method of the mixin class Safety will be invoked that increments the counter and continues with next to call the shadowed method, here the method push of the Stack implementation that actually pushes the item. The same happens, when s2 pop is invoked, first the method of Safety is called, then the method of the Stack. When the stack is empty (the value of count reaches 0), and pop is invoked, the mixin class Safety generates an error message (raises an exception), and does not invoke the method of the Stack.
The last two commands in Listing 8 use introspection to query for the objects s1 and s2 the order in which the classes are processed. This order is called the precedence order and is obtained via info precedence. We see that the mixin class Safety is only in use for s2, and takes there precedence over Stack. The common root class nx::Object is for both s1 and s2 the base class.
Note that the class Safety is only mixed into a single object (here s2), therefore we refer to this case as a per-object mixin. Figure 9 shows the class diagram, where the class Safety is used as a per-object mixin for s2.
The class Safety can be used as well in other ways, such as e.g. for defining classes for safe stacks <<xmp-class-safestack,
1 2 3 4 5 6 7 | # # Create a safe stack class by using Stack and mixin # Safety # Class create SafeStack -superclass Stack -mixin Safety SafeStack create s3 |
The difference to the case with the per-object mixin is that now, Safety is mixed into the definition of SafeStack. Therefore, all instances of the class SafeStack (here the instance s3) will be using the safety definitions. for this definition.
Note that we could use Safety as well as a per-class mixin on Stack. In this case, all stacks would be safe stacks and we could not provide a selective feature selection (which might be perfectly fine).
2.4. Define Different Kinds of Stacks
The definition of Stack is generic and allows all kind of elements to be stacked. Suppose, we want to use the generic stack definition, but a certain stack (say, stack s4) should be a stack for integers only. This behavior can be achieved by the same means as introduced already in Listing 5, namely object-specific methods.
1 2 3 4 5 6 7 8 9 10 11 | Stack create s4 { # # Create a stack with a object-specific method # to check the type of entries # :public method push {thing:integer} { next } } |
The program snippet in Listing 12 defines an instance s4 of the class Stack and provides an object specific method for push to implement an integer stack. The method pull is the same for the integer stack as for all other stacks, so it will be reused as usual from the class Stack. The object-specific method push of s4 has a value constraint in its argument list (thing:integer) that makes sure, that only integers can be stacked. In case the argument is not an integer, an exception will be raised. Of course, one could perform the value constraint checking as well in the body of the method proc by accepting an generic argument and by performing the test for the value in the body of the method. In the case, the passed value is an integer, the push method of Listing 12 calls next, and therefore calls the shadowed generic definition of push as provided by Stack.
1 2 3 4 5 6 7 8 9 10 | nx::Class create IntegerStack -superclass Stack { # # Create a Stack accepting only integers # :public method push {thing:integer} { next } } |
An alternative approach is shown in Listing 13, where the class IntegerStack is defined, using again the method definition use for s4, this time on the class level.
2.5. Define Class Specific Methods
In our previous examples we defined methods provided by classes (applicable for its instances) and object-specific methods (methods defined on objects, only applicable for these objects). In this section, we introduce methods defined on classes, which are only applicable for the class objects. Such methods are sometimes called class methods or "static methods".
In NX classes are objects with certain properties (providing methods for instances, managing object life-cycles; we will come to this later in more detail). Since classes are objects, we can define as well object-specific methods for the class objects. However, since :method applied on classes defines methods for instances, we have to use the method-modifier class to denote methods to be applied on the class itself. Note that class methods are not inherited to instances. These methods defined on the class object are actually exactly same as the object-specific methods in the examples above.
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 | nx::Class create Stack2 { :public class method available_stacks {} { return [llength [:info instances]] } :variable 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 } } Stack create s1 Stack create s2 puts [Stack available_stacks] |
The class Stack2 in Listing 14 consists of the the earlier definition of the class Stack extended by the class-specific method available_stacks, that returns the current number of instances of the stack. The final command puts (line 26) prints 2 to the console.
The class diagram in Figure 15 shows the diagrammatical representation of the class object-specific method available_stacks. We omit here the common root class. Since every class is a specialization of the common root class nx::Object, the common root class is often omitted from the class diagrams.
3. Basic Language Features of NX
3.1. Variables and Properties
In general, NX does not need variable declarations. It allows to create, modify or variables on the fly by using e.g. the Tcl commands set and unset. Depending on the variable name (or more precisely, depending on the prefix consisting of colons :), a variable is either local to a method, or an instance variable, or a global variable. The rules are:
-
A variable without any colon prefix refers typically to a method scoped variable (the variable is created at the begin of the invocation of the method and deleted, when the method ends); In the example below, the variable a is method scoped.
-
A variable with a single colon prefix refers to an instance variable (the variable is part of the object, when the object is destroyed, the variable is deleted as well. In the example below, the variable b is an instance variable.
-
a variable with two leading colons refers to a global variable (the lifespan ends when te variable is explicitly unset or the script ends). Also variables in placed in Tcl namespaces are global variables. In the example below, the variable c is a global variable.
1 2 3 4 5 6 7 8 9 10 11 | Class create Foo { :method foo args {...} # Method scoped variable a set a 1 # Instance variable b set :b 2 # Global variable/namespaced variable c set ::c 3 } } |
Listing 16 shows a method foo of some class Foo referring to differently scoped variables.
3.1.1. Properties: Instance Variables with Accessors
So, in general, there is no need to define or declare instance variables in NX. However, in some cases, a definition is useful. For example, one can define properties on classes, which are inherited to subclasses, and which are used during object initialization. Consider the following example:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 | # # Define a class Person with properties "name" # and "birthday" # nx::Class create Person { :property name:required :property birthday } # # Define a class Student as specialization of Person # with additional properties # nx::Class create Student -superclass Person { :property matnr:required :property {oncampus:boolean true} } # # Create instances using object parameters # for the initialization # Person create p1 -name Bob Student create s1 -name Susan -matnr 4711 # Access property value via accessor method puts "The name of s1 is [s1 name]" |
We define here a class named Person with two properties, namely name and birthday.
We refer with the term property to an instance variable with accessors, where the property definition might carry as well value-constraints and a default value.
When the class Person is defined, NX provides as well automatically accessors. Accessors are methods named like the variables, which are used to access (to read and write) the underlying instance variables. Therefore, in our example, the class Person has two methods implied by the property definition, namely the method name and the method birthday.
The class Student is defined as a specialization of Person with two additional properties, namely matnr and oncampus. The property matnr is required (it has to be provided, when an instance of this class is created), and the property oncampus is boolean, and is per default set to true. Note that the class Student inherits the properties of Person, therefore it will have 4 properties in total.
The property definitions are also used for providing object parameters. These are non-positional parameters provided during object creation to supply values to the instance variables. In our listing, we create an instance of Person using the object parameter name and provide the value of Bob to the instance variable name. Similarly, we create an instance of Student using the two object parameters name and matnr. Finally we use the accessor method name to obtain the value of the instance variable name of object s1.
3.1.2. Instance Variables without Accessors
In some cases one would like to define instance variables without accessors, e.g. for keeping the internal state of an object. For this purpose, one can use the predefined method variable, which is in many respects similar to property. One difference is, that property uses the same syntax as for method parameters, and variable receives the default value as a separate argument (similar to the variable command in Tcl. The introductory Stack example in in Listing 2 used already the method variable.
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 | Class create Base { :variable x 1 # ... } Class create Derived -superclass Base { :variable y 2 # ... } # Create instance of the class Derived Derived create d1 # Object d1 has instance variables # x == 1 and y == 2 |
Note that the variable definitions are inherited in the same way as properties. The example in Listing 18 shows a class Derived that inherits from Base. When an instance d1 is created, it will contain the two instance variables x and y.
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 | Class create Base2 { # ... :method init {} { set :x 1 # .... } } Class create Derived2 -superclass Base2 { # ... :method init {} { set :y 2 next # .... } } # Create instance of the class Derived2 Derived2 create d2 |
In many other object oriented languages, the instance variables are initialized solely by the constructor, similar to class Derived2 in Listing 19 . This approach is certainly as well possible in NX. Note however, that the approach using constructors requires an explicit method chaining between the constructors and is less declarative.
3.2. Method Definitions
The basic building blocks of an object oriented program are objects, classes, which contain named pieces of code, the methods.
Methods are subroutines (pieces of code) associated with objects and/or classes. Every method has a name, it receives arguments and returns a value.
There are as well other program units, which are not associated with objects or classes. Examples for such units are Tcl procs or Tcl commands.
Methods might have different scopes, defining, on which kind of objects these methods are applicable. We describe this later in more detail. For the time being, we deal here with methods defined on classes, which are applicable for the instance of these classes.
3.2.1. Scripted Methods
Since NX is a scripting language, most methods are most likely scripted methods, where the method body contains Tcl code.
1 2 3 4 5 6 7 8 9 10 11 12 13 14 | # Define a class nx::Class create Dog { # Define a scripted method for the class :public method bark {} { puts "[self] Bark, bark, bark." } } # Create an instance of the class Dog create fido # The following line prints "::fido Bark, bark, bark." fido bark |
In the example above we create a class Dog with a scripted method named bark. The method body defines the code, which is executed when the method is invoked. In this example, the method bar will print out a line on the terminal starting with the object name (determined by the built in command self followed by "Bark, bark, bark.". This method is defined on a class (the class contains the method) and applicable to instances of the class (here the instance fido).
3.2.2. C-implemented Methods
Not all of the methods usable in NX are scripted methods. There are for example predefined methods, that we used already in our examples, which are implemented in C. For example, in Listing 20 we used the method create to create the class Dog and to create the dog instance fido.
Also application developer might define their own functions in C, but this is an advanced topic, not covered here. However, application developer might reuse some generic C code to define their own C-implemented methods. Such methods are for example accessors, forwarders and aliases.
An accessor is a (in most cases) C-implemented method to access instance variables of an object. A call to an accessor with no arguments uses the accessor as a getter, obtaining the value of the associated variable. A call to an accessor with an argument uses it as a setter, setting the value of the associated variable.
We used accessors as well already in the section about properties, which define accessors automatically.
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 | nx::Class create Dog { :public method bark {} { puts "[self] Bark, bark, bark." } :method init {} { Tail create [self]::tail} } nx::Class create Tail { :property {length:double 5} :public method wag {} {return Joy} } # Create an instance of the class Dog create fido # Use the accessor "length" as a getter, to obtain the value # of a property. The following call returns the length of the # tail of fido fido::tail length # Use the accessor "length" as a setter, to alter the value # of a property. The following call changes the length of # the tail of fido fido::tail length 10 # Proving an invalid values will raise an error fido::tail length "Hello" |
Listing 21 shows an extended example, where every doc has a tail. The object tail is created as a subobject of the dog in the constructor init. The subobject can be accessed by providing the full name of the subobject fido::tail. The method length is an C-implemented accessor, that enforces the value constraint (here a floating point number, since length uses the value constraint double).
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 | nx::Class create Dog { :public method bark {} { puts "[self] Bark, bark, bark." } :method init {} { Tail create [self]::tail :public forward wag [self]::tail wag } } nx::Class create Tail { :property {length 5} :public method wag {} {return Joy} } # Create an instance of the class Dog create fido # The invocation of "fido wag" is delegated to "fido::tail wag". # Therefore, the following method returns "Joy". fido wag |
Listing 22 again extends the example by adding a forwarder named wag to the object (e.g. fido) that redirects all calls of the form fido wag with arbitrary arguments to the subobject fido::tail.
A forwarder is a C-implemented method to redirect an invocation for a certain method to either a method of other object or to some other method of the same object. Forwarding an invocation of a method to some other object is a means of delegation.
The functionality of the forwarder can be certainly as well be implemented as a scripted method, but for the most common cases, the forward implementation is more efficient, and the forward method expresses the intention of the developer.
The forwarder have several options to change e.g. the order of the arguments, to substitute certain patterns in the argument list etc. This will be described in later sections.
3.2.3. Method-Aliases
A method alias is a means to register an existing method, a Tcl proc or command under as a method with a certain name on a class or object.
In some way, the method alias is a restricted form of a forwarder, but it does not support delegation to different objects and argument reordering. The advantage of the method alias is it has close to zero overhead, especially for aliasing c-implemented methods, since the methods are simple registered under a different name.
1 2 3 4 5 6 7 8 9 10 11 12 13 | nx::Class create Dog { :public method bark {} { puts "[self] Bark, bark, bark." } # Define a public alias for the method "bark" :public alias warn [:info method handle bark] # ... } # Create an instance of the class Dog create fido # The following line prints "::fido Bark, bark, bark." fido warn |
Listing 23 extends the last example by defining an alias for the method "bark". The example just shows the bare mechanism. In general, method aliases are a very powerful means for reusing pre-existing functionality. The full object system of NX and XOTcl2 is built from aliases, where e.g. the same functionality is available in NX and XOTcl2 under different names. Method aliases are as well a means for implementing traits in NX.
3.3. Method Protection
All kinds of methods might have different kind of protections in NX. The call-protection defines from which calling context methods might be called. The Next Scripting Framework supports as well redefinition protection for methods.
NX distinguished between public, protected and private methods, where the default call-protection is "protected".
A public method can be called from every context. A protected method can only be invoked from the same object. A private method can be only invoked from methods defined on the same entity (e.g. defined on the same class) via my -local.
All kind of methods protection are applicable for all kind of methods, either scripted or C-implemented.
The distinction between public and protected is an instrument to define an interface for classes. Public methods are for consumer of the classes. Public methods define the intended ways of reusing classes and objects for consumers. Protected methods are intended for the implementor of the class or subclasses and not for public usage. The distinction between protected and public reduces the coupling between consumers and the implementation and offers more flexibility to the developer.
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 | nx::Class create Foo { # Define a public method :public method foo {} { # .... return [:helper] } # Define a protected method :method helper {} { return 1 } } # Create an instance of the class: Foo create f1 # The invocation of the public method "foo" returns 1 f1 foo # The invocation of the protected method "helper" raises an error: f1 helper |
Note that we could have as well used :protected method helper … in the above example, but we can omit protected, since it is the default method call protection.
The method call-protection of private goes one step further and helps to hide implementation details also for implementors of subclasses. Private methods are a means for avoiding unanticipated name clashes. Consider the following example:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 | nx::Class create Base { :private method helper {a b} { expr {$a + $b} } :public method foo {a b} { my -local helper $a $b } } nx::Class create Sub -superclass Base { :public method bar {a b} { my -local helper $a $b } :private method helper {a b} { expr {$a * $b} } :create s1 } s1 foo 3 4 ;# returns 7 s1 bar 3 4 ;# returns 12 s1 helper 3 4 ;# raises error: unable to dispatch method helper |
The base class implements a public method foo using the helper method named helper. Also the derived class implements a public method bar, which is also using a helper method named helper. When we create an instance s1 from the derived class, we can call the method foo which uses in turn the private method of the base class. Therefore, foo called with the arguments 3 and 4 returns its sum. If we would not have used my -local for invoking the helper, s1 would have tried to call the helper of Sub, which would be incorrect. For all other purposes, the private methods are "invisible" in all situations, e.g. when mixins are used, or within the next-path, etc.
By using my -local for the invocation it is possible to call just the local definition of the method. If we would call the method as usual, the resolution order would be the same as usual, starting with filters, mixins, per-object methods and the full intrinsic class hierarchy.
3.4. Applicability of Methods
As defined above, a method is a subroutine defined on an object or class. This object (or class) contains the method. If the object (or class) is deleted, the contained methods will be deleted as well.
3.4.1. Inherited Methods
Typically, methods are defined on a class and these methods are applicable to the instances (direct or indirect) of this class. These methods are inherited methods.
In the following example method foo is an inherited method defined on class C.
1 2 3 4 5 6 7 8 | nx::Class create C { :public method foo {} {return 1} :create c1 } # Method "foo" is defined on class "C" # and applicable to the instances of "C" c1 foo |
There are many programming languages that allow only this type of methods. However, NX allows as well to define methods on objects.
3.4.2. Object Methods
Methods contained in objects are per-object methods, which are only applicable on the object, on which they are defined.
The following example defines a object specific method bar on the instance c1 of class C, and as well the object specific method baz defined on the object o1. Note that we can define a per-object method that shadows (redefines) for this object an inherited method.
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 | nx::Class create C { :public method foo {} {return 1} :create c1 { :public method foo {} {return 2} :public method bar {} {return 3} } } # Method "bar" is on object specific method of "c1" c1 bar # object-specific method "foo" returns 2 c1 foo # Method "baz" is on object specific method of "o1" nx::Object create o1 { :public method baz {} {return 4} } o1 baz |
3.4.3. Class Methods
A class method is a method defined on a class, which is only applicable to the class itself.
In NX, all classes are objects as well. Classes are certainly special kind of objects, that have the ability to e.g. create instances and to provide methods to the instances. Classes manage their instances.
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 | nx::Class create C { :public class method bar {} {return 2} :public method foo {} {return 1} :create c1 } # Method "bar" is a class method of class "C" C bar # Method "foo" is an inherited method of "C" c1 foo # When trying to invoke the class method on the # instance, an error will be raised. c1 bar |
In several other object oriented programming languages, class methods are called "static methods".
3.5. Ensemble Methods
…
3.6. Method Resolution
=== Parameters
NX provides a generalized mechanism for passing values to either
methods (we refer to these as _method parameters_) or to objects
(these are called _object parameters_). Both kind of parameters
might have different features, such as:
- Positional and non-positional parameters
- Required and non-required parameters
- Default values for parameters
- Value-checking for parameters
- Multiplicity of parameters
TODO: complete list above and provide a short summary of the section
Before we discuss method and object parameters in more detail, we
describe the parameter features in the subsequent sections based on
method parameters.
==== Positional and Non-Positional Parameters
If the position of a parameter in the list of formal arguments
(e.g. passed to a function) is significant for its meaning, this is a
_positional_ parameter. If the meaning of the parameter is independent
of its postion, this is a _non-positional_ parameter. When we call a
method with positional parameters, the meaning of the parameters (the
association with the argument in the argument list of the method) is
determined by its position. When we call a method with non-positional
parameters, their meaning is determined via a name passed with the
argument during invocation.
[[xmp-posnonpos]]
.Listing {counter:figure-number}: Positional and Non-Positional Method Parameters
{set:xmp-posnonpos:Listing {figure-number}}
[source,tcl,numbers]
--------------------------------------------------
nx::Object create o1 {
#
# Method foo has positional parameters:
#
:public method foo {x y} {
puts "x=$x y=$y"
}
#
# Method bar has non-positional parameters:
#
:public method bar {-x -y} {
puts "x=$x y=$y"
}
#
# Method baz has non-positional and
# positional parameters:
#
:public method baz {-x -y a} {
puts "x? [info exists x] y? [info exists y] a=$a"
}
}
# invoke foo (positional parameters)
o1 foo 1 2
# invoke bar (non-positional parameters)
o1 bar -y 3 -x 1
o1 bar -x 1 -y 3
# invoke baz (positional and non-positional parameters)
o1 baz -x 1 100
o1 baz 200
o1 baz -- -y
--------------------------------------------------
Consider the example in <<xmp-posnonpos, {xmp-posnonpos}>>. The method
+foo+ has the argument list +x y+. This means that the first argument
is passed in an invocation like +o1 foo 1 2+ to +x+ (here, the value
+1+), and the second argument is passed to +y+ (here the value +2+).
Method +bar+ has in contrary just with non-positional arguments. Here
we pass the names of the parameter together with the values. In the
invocation +o1 bar -y 3 -x 1+ the names of the parameters are prefixed
with a dash ("-"). No matter whether in which order we write the
non-positional parameters in the invocation (see line 30 and 31 in
<<xmp-posnonpos, {xmp-posnonpos}>>) in both cases the variables +x+
and +y+ in the body of the method +bar+ get the same values assigned
(+x+ becomes +1+, +y+ becomes +3+).
It is certainly possible to combine positional and non-positional
arguments. Method +baz+ provides two non-positional parameter (+-y+
and +-y+) and one positional parameter (namely +a+). The invocation in
line 34 passes the value of +1+ to +x+ and the value of +100+ to +a+.
There is no value passed to +y+, therefore value of +y+ will be
undefined in the body of +baz+, +info exists y+ checks for the
existence of the variable +y+ and returns +0+.
The invocation in line 35 passes only a value to the positional
parameter. A more tricky case is in line 36, where we want to pass
+-y+ as a value to the positional parameter +a+. The case is more
tricky since syntactically the argument parser might consider +-y+ as
the name of one of the non-positional parameter. Therefore we use +--+
(double dash) to indicate the end of the block of the non-positional
parameters and therefore the value of +-y+ is passed to +a+.
==== Optional and Required Parameters
Per default positional parameters are required, and non-positional
parameters are optional (they can be left out). By using parameter
options, we can as well define positional parameters, which are
optional, and non-positional parameters, which are required.
[[xmp-optional-req]]
.Listing {counter:figure-number}: Optional and Required Method Parameters
{set:xmp-optional-req:Listing {figure-number}}
[source,tcl,numbers]
--------------------------------------------------
nx::Object create o2 {
#
# Method foo has one required and one optional
# positional parameter:
#
:public method foo {x:required y:optional} {
puts "x=$x y? [info exists y]"
}
#
# Method bar has one required and one optional
# non-positional parameter:
#
:public method bar {-x:required -y:optional} {
puts "x=$x y? [info exists y]"
}
}
# invoke foo (one optional positional parameter is missing)
o2 foo 1
--------------------------------------------------
The example in <<xmp-optional-req, {xmp-optional-req}>> defined method +foo+
with one required and one optional positional parameter. For this
purpose we use the parameter options +required+ and +optional+. The
parameter options are separated from the parameter name by a colon. If
there are multiple parameter options, these are separated by commas
(we show this in later examples).
The parameter definition +x:required+ for method +foo+ is equivalent
to +x+ without any parameter options (see e.g. previous example),
since positional parameters are per default required. The invocation
in line 21 of <<xmp-optional-req, {xmp-optional-req}>> will lead to an
undefined variable +y+ in method +foo+, because no value us passed to
the optional parameter. Note that only trailing positional parameters might be
optional. If we would call method +foo+ of <<xmp-posnonpos,
{xmp-posnonpos}>> with only one argument, the system would raise an
exception.
Similarly, we define method +bar+ in <<xmp-optional-req,
{xmp-optional-req}>> with one required and one optional non-positional
parameter. The parameter definition +-y:optional+ is equivalent to
+-y+, since non-positional parameter are per default optional.
However, the non-positional parameter +-x:required+ is required. If we
invoke +bar+ without it, the system will raise an exception.
==== Default Values for Parameters
Optional parameters might have a default value, which will be used,
when not value is provided for this parameter. Default values can be
specified for positional and non-positional parameters.
[[xmp-default-value]]
.Listing {counter:figure-number}: Method Parameters with Default Values
{set:xmp-default-value:Listing {figure-number}}
[source,tcl,numbers]
--------------------------------------------------
nx::Object create o3 {
#
# Positional parameter with default value:
#
:public method foo {x:required {y 101}} {
puts "x=$x y? [info exists y]"
}
#
# Non-positional parameter with default value:
#
:public method bar {{-x 10} {-y 20}} {
puts "x=$x y? [info exists y]"
}
}
# use default values
o3 foo
o3 bar
--------------------------------------------------
In order to define a default value, the parameter specification must
be of the form of a 2 element list, where the second argument is the
default value. See for an example in
<<xmp-default-value,{xmp-default-value}>>.
==== Value Constraints
NX provides value constraints for all kind of parameters. By
specifying value constraints a developer can restrict the permissible
values for a parameter and document the expected values in the source
code. Value checking in NX is conditional, it can be turned on or off
in general or on a per-usage level (more about this later). The same
mechanisms can be used not only for input value checking, but as well
for return value checking (we will address this point as well later).
===== Built-in Value Constraints
NX comes with a set of built-in value constraints, which can be
extended on the scripting level. The built-in checkers are either the
native checkers provided directly by the Next Scripting Framework (the
most efficient checkers) or the value checkers provided by Tcl through
+string is ...+. The built-in checkers have as well the advantage that
they can be used also at any time during bootstrap of an object
system, at a time, when e.g. no objects or methods are defined. The
same checkers are used as well for all C-implemented primitives of NX
and the Next Scripting Framework.
[[img-value-checkers]]
image::value-checkers.png[align="center",title="General Applicable Value Checkers in NX"]
{set:img-value-checkers:Figure {figure-number}}
<<img-value-checkers, {img-value-checkers}>> shows the built-in
general applicable value checkers available in NX, which can be used
for all method and object parameters. In the next step, we show how to
use these value-checkers for checking permissible values for method
parameters. Then we will show, how to provide more detailed value
constraints.
[[xmp-value-check]]
.Listing {counter:figure-number}: Method Parameters with Value Constraints
{set:xmp-value-check:Listing {figure-number}}
[source,tcl,numbers]
--------------------------------------------------
nx::Object create o4 {
#
# Positional parameter with value constraints:
#
:public method foo {x:integer o:object,optional} {
puts "x=$x o? [info exists o]"
}
#
# Non-positional parameter with value constraints:
#
:public method bar {{-x:integer 10} {-verbose:boolean false}} {
puts "x=$x y=$y"
}
}
# The following invocation raises an exception
o4 foo a
--------------------------------------------------
Value contraints are specified as parameter options in the parameter
specifications. The parameter specification +x:integer+ defines +x+ as
a required positional parmeter which value is constraint to an
integer. The parameter specification +o:object,optional+ shows how to
combine multiple parameter options. The parameter +o+ is an optional
positional parameter, its value must be an object (see
<<xmp-value-check,{xmp-value-check}>>). Value constraints are
specified exactly the same way for non-positional parameters (see
method +bar+ in <<xmp-value-check,{xmp-value-check}>>).
[[xmp-check-parameterized]]
.Listing {counter:figure-number}: Parameterized Value Constraints
{set:xmp-check-parameterized:Listing {figure-number}}
[source,tcl,numbers]
--------------------------------------------------
#
# Create classes for Person and Project
#
Class create Person
Class create Project
nx::Object create o5 {
#
# Parameterized value constraints
#
:public method work {
-person:object,type=Person
-project:object,type=Project
} {
# ...
}
}
#
# Create a Person and a Project instance
#
Person create gustaf
Project create nx
#
# Use method with value constraints
#
o5 work -person gustaf -project nx
--------------------------------------------------
The native checkers +object+, +class+, +metaclass+ and +baseclass+ can
be further specialized with the parameter option +type+ to restrict
the permissible values to instances of certain classes. We can use for
example the native value constraint +object+ either for testing
whether an argument is some object (without further constraints, as in
<<xmp-default-value, {xmp-default-value}>>, method +foo+), or we can
constrain the value further to some type (direct or indirect instance
of a class). This is shown by method +work+ in
<<xmp-check-parameterized, {xmp-check-parameterized}>> which requires
the parameter +-person+ to be an instance of class +Person+ and the
parameter +-project+ to be an instance of class +Project+.
===== Scripted Value Constraints
The set of predefined value checkers can be extended by application
programs via defining methods following certain conventions. The user
defined value checkers are defined as methods of the class +nx::Slot+
or of one of its subclasses or instances. We will address such cases
in the next sections. In the following example we define two new
value checkers on class +nx::Slot+. The first value checker is called
+groupsize+, the second one is called +choice+.
[[xmp-user-types]]
.Listing {counter:figure-number}: Scripted Value Checker for Method Parameters
{set:xmp-user-types:Listing {figure-number}}
[source,tcl,numbers]
--------------------------------------------------
#
# Value checker named "groupsize"
#
::nx::Slot method type=groupsize {name value} {
if {$value < 1 || $value > 6} {
error "Value '$value' of parameter $name is not between 1 and 6"
}
}
#
# Value checker named "choice" with extra argument
#
::nx::Slot method type=choice {name value arg} {
if {$value ni [split $arg |]} {
error "Value '$value' of parameter $name not in permissible values $arg"
}
}
#
# Create an application class D
# using the new value checkers
#
Class create D {
:public method foo {a:groupsize} {
# ...
}
:public method bar {a:choice,arg=red|yellow|green b:choice,arg=good|bad} {
# ...
}
}
D create d1
# testing "groupsize"
d1 foo 2
d1 foo 10
# testing "choice"
d1 bar green good
d1 bar pink bad
--------------------------------------------------
In order to define a checker +groupsize+ a method of the name
+type=groupsize+ is defined. This method receives two arguments,
+name+ and +value+. The first argument is the name of the parameter
(mostly used for the error message) and the second parameter is
provided value. The value checker simply tests whether the provided
value is between 1 and 3 and raises an exception if this is not the
case (invocation in line 36 in <<xmp-user-types, {xmp-user-types}>>).
The checker +groupsize+ has the permissible values defined in its
method's body. It is as well possible to define more generic checkers
that can be parameterized. For this parameterization, one can pass an
argument to the checker method (last argument). The checker +choice+
can be used for restricting the values to a set of predefined
constants. This set is defined in the parameter specification. The
parameter +a+ of method +bar+ in <<xmp-user-types, {xmp-user-types}>>
is restricted to the values +red+, +yellow+ or +green+, and the
parameter +b+ is restricted to +good+ or +bad+. Note that the syntax
of the permissible values is solely defined by the definition of the
value checker in lines 13 to 17. The invocation in line 39 will be ok,
the invocation in line 40 will raise an exception, since +pink+ is not
allowed.
If the same checks are used in many places in the program,
defining names for the value checker will be the better choice since
it improves maintainability. For seldomly used kind of checks, the
parameterized value checkers might be more convenient.
==== Multiplicity
*****************************************************************************
*Multiplicity* is used to define whether a parameter should receive
single or multiple values.
*****************************************************************************
A multiplicity specification has a lower and an upper bound. A lower
bound of +0+ means that the value might be empty. A lower bound of +1+
means that the the parameter needs at least one value. The upper bound
might be +1+ or +n+ (or synonymously +*+). While the upper bound of
+1+ states that at most one value has to be passed, the upper bound of
+n+ says that multiple values are permitted. Other kinds of
multiplicity are currently not allowed.
The multiplicity is written as parameter option in the parameter
specification in the form _lower-bound_.._upper-bound_. If no
multiplicity is defined the default multiplicity is +1..1+, which
means: provide exactly one (atomic) value (this was the case in the
previous examples).
[[xmp-multiplicity]]
.Listing {counter:figure-number}: Method Parameters with Explicit Multiplicity
{set:xmp-multiplicity:Listing {figure-number}}
[source,tcl,numbers]
--------------------------------------------------
nx::Object create o6 {
#
# Positional parameter with an possibly empty
# single value
#
:public method foo {x:integer,0..1} {
puts "x=$x"
}
#
# Positional parameter with an possibly empty
# list of values value
#
:public method bar {x:integer,0..n} {
puts "x=$x"
}
#
# Positional parameter with a non-empty
# list of values
#
:public method baz {x:integer,1..n} {
puts "x=$x"
}
}
--------------------------------------------------
<<xmp-multiplicity, {xmp-multiplicity}>> contains three examples for
positional parameters with different multiplicities. Multiplicity is
often combined with value constraints. A parameter specification of
the form +x:integer,0..n+ means that the parameter +x+ receives a list
of integers, which might be empty. Note that the value constraints are
applied to every single element of the list.
The parameter specification +x:integer,0..1+ means that +x+ might be
an integer or it might be empty. This is one style of specifying that
no explicit value is passed for a certain parameter. Another style is
to use required or optional parameters. NX does not enforce any
particular style for handling unspecified values.
All the examples in <<xmp-multiplicity, {xmp-multiplicity}>> are for
single positional parameters. Certainly, multiplicity is fully
orthogonal with the other parameter features and can be used as well
for multiple parameters, non-positional parameter, default values,
etc.
== Advanced Language Features
...
=== Objects, Classes and Meta-Classes
...
=== Resolution Order and Next-Path
...
=== Details on Method and Object Parameters
The parameter specifications are used in NX for the following
purposes. They are used for
- the specification of input arguments of methods and commands, for
- the specification of return values of methods and commands, and for
- the specification for the initialization of objects.
We refer to the first two as method parameters and the last one as
object parameters. The examples in the previous sections all parameter
specification were specifications of method parameters.
*****************************************************************************
*Method parameters* specify properties about permissible values passed
to methods.
*****************************************************************************
The method parameter specify how methods are invoked, how the
actual arguments are passed to local variables of the invoked method
and what kind of checks should be performed on these.
*****************************************************************************
*Object parameters* are parameters that specify, with what values
instance variables of objects are initialized and how these objects
could be parameterized.
*****************************************************************************
Syntactically, object parameters and method parameters are the same,
although there are certain differences (e.g. some parameter options
are only applicable for objects parameters, the list of object
parameters is computed dynamically from the class structures, object
parameters are often used in combination with special setter methods,
etc.). Consider the following example, where we define the two
application classes +Person+ and +Student+ with a few properties.
[[xmp-object-parameters]]
.Listing {counter:figure-number}: Object Parameters
{set:xmp-object-parameters:Listing {figure-number}}
[source,tcl,numbers]
--------------------------------------------------
#
# Define a class Person with properties "name"
# and "birthday"
#
nx::Class create Person {
:property name:required
:property birthday
}
#
# Define a class Student as specialization of Person
# with and additional property
#
nx::Class create Student -superclass Person {
:property matnr:required
:property {oncampus:boolean true}
}
#
# Create instances using object parameters
# for the initialization
#
Person create p1 -name Bob
Student create s1 -name Susan -matnr 4711
# Access property value via accessor method
puts "The name of s1 is [s1 name]"
--------------------------------------------------
The class +Person+ has two properties +name+ and +birthday+, where the
property +name+ is required, the property +birthday+ is not. The
class +Student+ is a subclass of +Person+ with the additional required
property +matnr+ and an optional property +oncampus+ with the
default value +true+ (see <<xmp-object-parameters,
{xmp-object-parameters}>>). The class diagram below visualizes these
definitions.
[[img-object-parameters]]
image::object-parameter.png[align="center",title="System and Application Classes"]
{set:img-object-parameters:Figure {figure-number}}
In NX, these definitions imply that instances of the class of +Person+
have the properties +name+ and +birthday+ as _non-positional object
parameters_. Furthermore it implies that instances of +Student+ will
have the object parameters of +Person+ augmented with the object
parameters from +Student+ (namely +matnr+ and +oncampus+). Based on
these object parameters, we can create a +Person+ named +Bob+ and a
+Student+ named +Susan+ with the matriculation number +4711+ (see line
23 and 24 in <<xmp-object-parameters,
{xmp-object-parameters}>>). After the object +s1+ is created it has the
instance variables +name+, +matnr+ and +oncampus+ (the latter is
initialized with the default value).
==== Object Parameters for all NX Objects
The object parameters are not limited to the application defined
properties, also NX provides some predefined definitions. Since
+Person+ is a subclass of +nx::Object+ also the object parameters of
+nx::Object+ are inherited. In the introductory stack example, we used
+-mixin+ applied to an object to denote per-object mixins (see
<<xmp-using-class-safety, {xmp-using-class-safety}>>). Since +mixin+
is defined as a parameter on +nx::Object+ it can be used as an object
parameter +-mixin+ for all objects in NX. To put it in other words,
every object can be configured to have per-object mixins. If we would
remove this definition, this feature would be removed as well.
As shown in the introductory examples, every object can be configured
via a scripted initialization block (the optional scripted block
specified at object creation as last argument; see
<<xmp-object-stack, {xmp-object-stack}>> or
<<xmp-object-integer-stack, {xmp-object-integer-stack}>>). The
scripted block and its meaning are as well defined by the means of
object parameters. However, this object parameter is positional (last
argument) and optional (it can be omitted). The following listing shows
(simplified) the object parameters of +Person p1+ and +Student s1+.
[[xmp-object-parameter-list]]
.Listing {counter:figure-number}: Computed Actual Object Parameter (simplified)
{set:xmp-object-parameter-list:Listing {figure-number}}
[source,tcl,numbers]
--------------------------------------------------
Object parameter for Person p1:
-name:required -birthday ...
-mixin:mixinreg,alias,1..n -filter:filterreg,alias,1..n _:initcmd,optional
Object parameter for Student s1:
-matnr:required {-oncampus:boolean true}
-name:required -birthday ...
-mixin:mixinreg,alias,1..n -filter:filterreg,alias,1..n _:initcmd,optional
--------------------------------------------------
The actual values can be optained via introspection via +Person info
parameter definition+. The object parameter types +mixinreg+ and
+filterreg+ are for converting definitions of filters and mixins. The
object parameter type +initcmd+ says that the content of this variable
will be executed in the context of the object being created (before
the constructor +init+ is called). More about the object parameter
types later.
==== Object Parameters for all NX Classes
Since classes are certain kind of objects, classes are parameterized
in the same way as objects. A typical parameter for a class definition
is the relation of the class to its superclass.In our example, we have
specified, that +Student+ has +Person+ as superclass via the
non-positional object parameter +-superclass+. If no superclass is
specified for a class, the default superclass is
+nx::Object+. Therefore +nx::Object+ is the default value for the
parameter +superclass+.
Another frequently used parameter for classes is +-mixin+ to denote
per-class mixins (see e.g. the introductory Stack example in
<<xmp-class-safestack,{xmp-class-safestack}>>), which is defined in
the same way.
Since +Student+ is an instance of the meta-class +nx::Class+ it
inherits the object parameters from +nx::Class+ (see class diagram
<<img-object-parameters,{img-object-parameters}>>). Therefore, one can
use e.g. +-superclass+ in the definition of classes.
Since +nx::Class+ is a subclass of +nx::Object+, the meta-class
+nx::Class+ inherits the parameter definitions from the most general
class +nx::Object+. Therefore, every class might as well be configured
with a scripted initialization block the same way as objects can be
configured. We used actually this scripted initialization block in
most examples for defining the methods of the class. The following
listing shows (simplified) the parameters applicable for +Class
Student+.
[[xmp-class-parameter-list]]
.Listing {counter:figure-number}: Computed Parameters for a Class (simplified)
{set:xmp-class-parameter-list:Listing {figure-number}}
[source,tcl,numbers]
--------------------------------------------------
Object parameter for Class Student:
-mixin:mixinreg,alias,1..n -filter:filterreg,alias,1..n ...
{-superclass:class,alias,1..n ::nx::Object} ...
--------------------------------------------------
The actual values can be obtained via introspection via +nx::Class info
parameter definition+.
==== User defined Parameter Types
More detailed definition of the object parameter types comes here.
==== Slot Classes and Slot Objects
In one of the previous sections, we defined scripted (application
defined) checker methods on a class named +nx::Slot+. In general NX
offers the possibility to define value checkers not only for all
usages of parameters but as well differently for method parameters or
object parameters
[[img-slots]]
image::slots.png[align="center",title="Slot Classes and Objects"]
{set:img-slots:Figure {figure-number}}
==== Attribute Slots
Still Missing
- return value checking
- switch
- initcmd ...
- subst rules
- converter
- incremental slots
== Miscellaneous
=== Profiling
=== Unknown Handlers
NX provides two kinds of unknown handlers:
- Unknown handlers for methods
- Unknown handlers for objects and classes
==== Unknown Handlers for Methods
Object and classes might be equipped
with a method +unknown+ which is called in cases, where an unknown
method is called. The method unknown receives as first argument the
called method followed by the provided arguments
[[xmp-unknown-method]]
.Listing {counter:figure-number}: Unknown Method Handler
{set:xmp-unknown-method:Listing {figure-number}}
[source,tcl,numbers]
--------------------------------------------------
::nx::Object create o {
:method unknown {called_method args} {
puts "Unknown method '$called_method' called"
}
}
# Invoke an unknown method for object o:
o foo 1 2 3
# Output will be: "Unknown method 'foo' called"
--------------------------------------------------
Without any provision of an unknown method handler, an error will be
raised, when an unknown method is called.
==== Unknown Handlers for Objects and Classes
The next scripting framework provides in addition to unknown method
handlers also a means to dynamically create objects and classes, when
these are referenced. This happens e.g. when superclasses, mixins, or
parent objects are referenced. This mechanism can be used to implement
e.g. lazy loading of these classes. Nsf allows to register multiple
unknown handlers, each identified by a key (a unique name, different
from the keys of other unknown handlers).
[[xmp-unknown-class]]
.Listing {counter:figure-number}: Unknown Class Handler
{set:xmp-unknown-class:Listing {figure-number}}
[source,tcl,numbers]
--------------------------------------------------
::nx::Class public class method __unknown {name} {
# A very simple unknown handler, showing just how
# the mechanism works.
puts "***** __unknown called with <$name>"
::nx::Class create $name
}
# Register an unknown handler as a method of ::nx::Class
::nsf::object::unknown::add nx {::nx::Class __unknown}
::nx::Object create o {
# The class M is unknown at this point
:mixin add M
# The line above has triggered the unknown class handler,
# class M is now defined
puts [:info mixin classes]
# The output will be:
# ***** __unknown called with <::M>
# ::M
}
--------------------------------------------------
The Next Scripting Framework allows to add, query, delete and list unknown handlers.
[[xmp-unknown-registgration]]
.Listing {counter:figure-number}: Unknown Handler registration
{set:xmp-unknown-registgration:Listing {figure-number}}
[source,tcl,numbers]
--------------------------------------------------
# Interface for unknown handlers:
# nsf::object::unknown::add /key/ /handler/
# nsf::object::unknown::get /key/
# nsf::object::unknown::delete /key/
# nsf::object::unknown::keys
--------------------------------------------------
[bibliography]
.References
- [[Zdun, Strembeck, Neumann 2007]] U. Zdun, M. Strembeck, G. Neumann:
Object-Based and Class-Based Composition of Transitive Mixins,
Information and Software Technology, 49(8) 2007 .
- [[Neumann and Zdun 1999a]] G. Neumann and U. Zdun: Filters as a
language support for design patterns in object-oriented scripting
languages. In Proceedings of COOTS'99, 5th Conference on
Object-Oriented Technologies and Systems, San Diego, May 1999.
- [[Neumann and Zdun 1999b]] G. Neumann and U. Zdun: Implementing
object-specific design patterns using per-object mixins. In Proc. of
NOSA`99, Second Nordic Workshop on Software Architecture, Ronneby,
Sweden, August 1999.
- [[Neumann and Zdun 1999c]] G. Neumann and U. Zdun: Enhancing
object-based system composition through per-object mixins. In
Proceedings of Asia-Pacific Software Engineering Conference (APSEC),
Takamatsu, Japan, December 1999.
- [[Neumann and Zdun 2000a]] G. Neumann and U. Zdun: XOTCL, an
object-oriented scripting language. In Proceedings of Tcl2k: The
7th USENIX Tcl/Tk Conference, Austin, Texas, February 2000.
- [[Neumann and Zdun 2000b]] G. Neumann and U. Zdun: Towards the Usage
of Dynamic Object Aggregations as a Form of Composition In:
Proceedings of Symposium of Applied Computing (SAC'00), Como,
Italy, Mar 19-21, 2000.
- [[Neumann and Sobernig 2009]] G. Neumann, S. Sobernig: XOTcl 2.0 - A
Ten-Year Retrospective and Outlook, in: Proceedings of the Sixteenth
Annual Tcl/Tk Conference, Portland, Oregon, October, 2009.
- [[Ousterhout 1990]] J. K. Ousterhout: Tcl: An embeddable command
language. In Proc. of the 1990 Winter USENIX Conference, January 1990.
- [[Ousterhout 1998]] J. K. Ousterhout: Scripting: Higher Level
Programming for the 21st Century, IEEE Computer 31(3), March 1998.
- [[Wetherall and Lindblad 1995]] D. Wetherall and C. J. Lindblad: Extending Tcl for
Dynamic Object-Oriented Programming. Proc. of the Tcl/Tk Workshop '95,
July 1995.