Dear German,

Granted, I am not experienced in objects, although a couple of years ago I went back to a local community college for a nice Java course where I learned about OO and concepts like Inheritance and Encapsulation. So, needless to say, I was able to understand itcl right away and I am having the hardest time understanding xotcl. So, I gather that xotcl seems more versatil (and hence more powerfull?)...is [incr tcl] good enough? [incr tcl] seems easy (to me, with my Java knowledge) to grasp and program. How does xotcl compare?

itcl is more or less the a mapping of the basic concepts of C++ to Tcl. If you are familiar with C++ and Java, there is not much new to learn.

The basic object model of XOTcl is different. While the object model of C++ is class based and says_ "look at the classes, and you know exactly what your objects are", the basic object model of XOTcl is instance based, and the relation between objects and classes (and between classes) are relations in the sense of associations.

This basic concept has the following consequences in XOTcl:

- all state is kept in objects (instance variables)

- classes are objects (can contain variables), with two additional properties * classes are manager objects controlling the life-cycle of their instances (allocate, init, destroy), classes know their instances and vice versa * classes provide methods (behavior) for their instances

- the relation between an instance and its class is a relation that can be changed any time, objects can be re-classed (when an instance of a car crashes hard against a tree, its class and behavior changes)

- The relation between classes can be changes as well (e.g. the superclass relation can be changed)

In XOTcl, everything can be changed dynamically, everything is defined incrementally, while in itcl, one needs a complete class definition/declaration. Look at the following example:

Class create C C create c1

The first statement creates a class named C, the second statement creates an instance of this class named c1.

Now, we define a specify a specific behavior for class C:

C instproc foo {} { puts "hello world" }

This method can be used for instance c1:

c1 foo

What have we done now? Firstly, we have created an object c1, and later, we provided a method for its class C. Every XOTcl statement can change the behavior of existing objects. This might sound scary for someone seeking protection in OO. However, this flexibility is essentially the same that Tcl provides.

----

Let us look at the classical Stack example, and see a few variants of the theme.

Firstly we define a stack very similar style as an ensemble in Tcl 8.5 (a namespace, where the name of the namespace is a command).

We define an object s0, which is a namespace containing a few Tcl procs (push, pop) and the Tcl variable things:

Object create s0

s0 set things ""

s0 proc push {thing} { my instvar things set things [concat [list $thing] $things] return $thing }

s0 proc pop {} { my instvar things set top [lindex $things 0] set things [lrange $things 1 end] return $top }

Now we can use the stack s0

s0 push a s0 push b s0 push c puts "[s0 pop] [s0 pop] [s0 pop]"

The last statement prints "c b a". This example showed, how to define object-specific behavior.

----

In many situations, we want to have many stacks, therefore we define a class Stack generalizing from the basic behavior:

Class create Stack

Stack instproc init {} { my set things "" }

Stack instproc push {thing} { my instvar things set things [concat [list $thing] $things] return $thing }

Stack instproc pop {} { my instvar things set top [lindex $things 0] set things [lrange $things 1 end] return $top }

This class Stack can be used as follows

Stack create s1 s1 push a s1 push b s1 push c puts "[s1 pop] [s1 pop] [s1 pop]"

So far, there is nothing special in this Stack definition in XOTcl.

Now the Stack s1 is empty. What happens, when we do one more pop?

puts [s1 pop]

This statement returns an empty string. This means that the definition is unsafe, since it can't distinguish between a pop of an previously pushed empty element and a pop with the empty stack.

----

Let us define Safety by a separate class

Class create Safety

Safety instproc init {} { my set count 0 next }

Safety instproc push {thing} { my incr count next }

Safety instproc pop {} { if {[my set count] == 0} then { error "stack empty!" } my incr count -1 next }

The class Safety maintains a counter to keep track the number of stacked elements (certainly, there are other ways to implement Safety as well).

What's new is that we can mix in Safety into the Stack definition

Stack s2 -mixin Safety s2 push a s2 push b s2 push c puts "[s2 pop] [s2 pop] [s2 pop]" puts [s2 pop]

If we run these statements, an error is generated. What have we done? We have now an unsafe stack s1 and a safe stack s2. The s2 has safety mixed in. Safety is a per-object mixin for object s2. The per-object mixin shadows (overloads) the methods of the stack. Every method in Safety has a "next" statement, that invokes the shadowed methods.

Certainly, it is possible to remove Safety dynamically (or after some testing), or to provide other mixins for tracing, etc. Mixins are a powerful means to compose behavior.

----

Well, this was only the first glimpse at XOTcl. XOTcl distinguished between per-object mixins and per-class mixins, it provides filters to catch arbitrary calls), all these relations can be altered on the fly. Since most things can change at arbitrary times, XOTcl has some self-awareness to figure out its current state and relations (through introspection).

One can say for sure that XOTcl is more flexible and dynamic than itcl. Whether this flexibility is wanted or not, is a question that a programmer has to decide. XOTcl is not a means to constrain a programmer such he can do "only the right things" (no programming language can avoid bad programs) but a means to empower a programmer to do complex things quite easy.

I'm just having a hard time separating Objects and Classes, each with its own definitions and methods, etc. By the way, the soccer team example did not include anything on Objects, everything was Classes...so, I was up for a surprise when they started to talk about Objects in the same way they did about Classes. The following statements hit the nail right on the head for me:

Does the text above help? Please let me know when you find sentences or concepts hard to understand and not explained enough. Any suggestions are welcome.

-gustaf neumann