Migration Guide for the the Next Scripting Language

... general text, maybe partly from slides/paper .... TODO: Maybe we should not refer to ::nsf here and import instead the "needed" commands into ::nx namespace.

In general, the Next Scripting Language differs from XOTcl in the following respects:

• The Next Scripting Language has a much smaller interface (less predefined methods) than XOTcl.

• The Next Scripting Language favors a stronger form of encapsulation than XOTcl. Calling the own methods or accessing the own instance variables is typographically easier and computationally faster than these operations on other objects. This behavior is achieved via resolvers an makes the definition of methods necessary in XOTcl obsolete. On the other hand, XOTcl is complete symmetrical in this respect.

  The encapsulation of Next Scripting is weak; a programmer can still access e.g. other variables via some idioms, but this makes these accesses implicit and is more typing effort. Through the weak encapsulation a programmer should be encouraged to implement methods to provide access to instance variables.

• The Next Scripting Language provides means of method protection.

• The Next Scripting Language provides scripted init blocks for objects and classes (XOTcl used the dash "-" mechanisms to set variables and invoke methods upon object creation).

• The Next Scripting Language provides much more orthogonal means to define and name scripted and c-implemented methods.

• The Next Scripting Language provides an orthogonal framework for parametrization of methods and objects.

Class create Stack {

   :method init {} {
     set :things ""
   } 

   :method push {thing} {
      set :things [linsert ${:things} 0 $thing] 
      return $thing
   }
  
   :method pop {} {
      set top [lindex ${:things} 0]
      set :things [lrange ${:things} 1 end]
      return $top
   }
}

Figure 1: Stack example in the Next Scripting Language

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]
   return $top
}

Figure 2: Stack example in XOTcl

Using XOTcl 2.0 and the Next Scripting Language in the Next Scripting Framework 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 supports primarily XOTcl 2.0 (highly compatible with XOTcl 1.*) and the Next Scripting Language (XOTcl provides about twice as many predefined built-in methods compared to the Next Scripting Language).

A single Tcl interpreter can host both, XOTcl and the Next Scripting Language at the same time. This makes migration from XOTcl to Next easier. The following example script shows to use in a single script XOTcl and Next:

   namespace eval mypackage {

      package require XOTcl 2.0

      # Import XOTcl into the current namespace
      namespace import -force ::xotcl::*

      # Define a class using XOTcl
      Class C1
      C1 instproc foo {} {puts "hello world"}

      # Import Next into the current namespace
      namespace import -force ::nx::*

      # Define a class using Next
      Class create C2 {
         :method foo {} {puts "hello world"}
      }
   }

"Switching" between XOTcl and Next effectively means the load some packages (if needed) and to import either the base classes (Object and Class) of XOTcl or Next into the current namespace.

XOTcl Idioms in the Next Scripting Language

Defining Objects and Classes

Defining Methods

Scripted Methods Defined in the Init-block of a Class/Object or with Separate Calls

Define Different Kinds of Methods

Method Modifiers and Method Protection

Resolvers

Note that the Next resolvers can be used in the XOTcl 2.* environment as well.

Invoking Methods

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. On the contrary, in XOTcl, the variable access to own and other variables are completely symmetric.

In Next Scripting, access to local variables are performed via primarily via name resolvers, but using the standard tcl commands (like e.g. set, incr, append, info exists, etc.). In XOTcl, it is common to provide same-named methods registered on ::xotcl::Object for such purposes. This is one of the reasons, why the Next Scripting Language has a much smaller interface (less predefined methods). It is possible for an application program to register XOTcl-like methods in the Next Scripting Language via the primitives of the Next Scripting Framework.

XOTcl	Next Scripting Language
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 }	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   } }
... instproc ... {    my set varname value }	# set own instance variable to a value via resolver # (prefered and fastest way) ... method ... {    set :newVar value }
... instproc ... {    my instvar newVar    set newVar value }	# set own instance variable via variable import ... method ... {    ::nx::var import [self] varname    set varname value }
... instproc ... {    set newVar [my set otherVar] }	# read own instance variable ... method ... {    set newVar [set :otherVar] } ... method ... {    set newVar ${:otherVar} }
... instproc ... {    my exists varname }	# Test existence of own instance variable ... method ... {    info :varname } ... method ... {    ::nx::var exists [self] varname }

Accessing Instance Variables of other Objects

Object Parameters

Method Parameters

Interceptors

Register Mixin Classes and Mixin Guards

Register Filters and Filter Guards

Introspection

List methods defined by objects

List methods defined by classes

List class object specific methods

List callable methods

List object/class where some method is defined

List definition of scripted methods defined by classes

List definition of scripted object specific methods

For definition of class object specific methods, use modifier object as shown in examples above.

List Filter or Mixins

List definition of methods defined by aliases, setters or forwarders

List fully qualified name of method

List type of a method

List the scope of mixin classes

Check properties of object and classes

Callstack Introspection

Predefined Methods

Dispatch, Aliases, etc.

Assertions

Method Protection

Incompatibilities between XOTcl 2.0 and XOTcl 1.*

Resolvers

The resolvers of the Next Scripting Framework are used as well within XOTcl 2.0. When names starting with single colons are used in XOTcl 1.* scripts, conflicts will arise.

Slots

All slots are now always next-scripting objects.

Obsolete commands

Parameterclasses 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 was just a comment, while Next enforces it.

Different results

• none?

Exit Handlers

The exit hander interface changed from a method of ::xotcl::Object into three Tcl procs in the ::nsf namespace. Next provides now:

   ::nsf::setExitHandler script
   ::nsf::getExitHandler
   ::nsf::unsetExitHandler