Index: doc/next-migration.html =================================================================== diff -u -r05f429e6986a7ed8c8d36cad30609f457ec93281 -rf739c3b063405846cdcd9e399832860b78eb9068 --- doc/next-migration.html (.../next-migration.html) (revision 05f429e6986a7ed8c8d36cad30609f457ec93281) +++ doc/next-migration.html (.../next-migration.html) (revision f739c3b063405846cdcd9e399832860b78eb9068) @@ -20,10 +20,15 @@ font-style: italic; color: #888888; } +pre.code { + border: 1px solid grey; + padding: 20px 60px; +} pre i { font-style: italic; color: green; } +p.caption {text-align: center;} th {color: #888888;} td hr { color: #FFFFFF; @@ -55,24 +60,102 @@
-... general text, maybe partly from slides/paper .... - - TODO: Maybe we should not refer to ::nx::core here and import instead the "needed" commands into ::nx namespace. +
In general, the Next Scripting Language differs from XOTcl in the following +respects: +
+ +
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.
+ +
+ +
+ +
+ +
+ +
+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 + } +} ++ + + +
+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 +} ++ +
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 builtin +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 builtin +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 @@ -347,7 +430,7 @@ to an instance variable, and a colon-prefixed function name refers to a method. The sub-sections below provide detailed examples. -
Note that the Next resolvers are used in the XOTcl 2.* environment +
Note that the Next resolvers can be used in the XOTcl 2.* environment as well.
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 |
---|---|