Stooop is an extension to the great Tcl language written in Tcl itself. It provides the programmer with object oriented facilities modeled after the C++ programming language while following the Tcl language philosophy.
This document contains general information, reference information and many examples designed to help the programmer understand and use the stooop Tcl extension.
A working knowledge of object oriented programming techniques and a related programming language (C++ is recommended) helps understand this document.
After some time writing Tcl/Tk code, I felt I needed a way to better organize my code, and why not use an object oriented approach, since I knew (but does anybody really? :^) C++. As I use Tcl quite extensively in several commercial applications, I decided to use a strict Tcl implementation for my object oriented extension. This approach would allow instantaneous porting to other platforms, should Tcl itself be ported (this has since been the case since Tcl and Tk are now also available on Windows PCs and Mac Intosh platforms).
However, as great as Tcl is, it is an interpreted language, and as such offers less performance than a compilable language (although Tcl may become compilable in 1996). So great care was taken so that this extension would have as little impact as possible on performance.
Actually, some say that designing your code in an object oriented way would improve its performance, and I tend to agree with them.
Stooop only introduces 2 new operators: new, delete, a virtual specifier, and a classof operator for runtime type identification. Along with a few coding conventions, that is basically all you need to know to use stooop. Stooop is meant to be as simple to use as possible.
Those looking for better performance may want to use the dynamically loadable extension that provides a faster implementation for the operators (see Dynamically loadable extension).
Let us start with a code sample that will give you some feeling on how stooop works:
proc shape::shape {this x y} {
# base class constructor
set shape($this,x) $x
set shape($this,y) $y
}
proc shape::~shape {this} {
# base class destructor
}
# pure virtual draw: must be implemented in derived classes
virtual proc shape::draw {this}
virtual proc shape::rotate {this angle} {
# do nothing by default
}
proc shape::move {this x y} {
set shape($this,x) $x
set shape($this,y) $y
shape::draw $this
}
proc triangle::triangle {this x y} shape {$x $y} {
# derived from shape
# triangle constructor implementation
}
proc triangle::~triangle {this} {}
proc triangle::draw {this} {
# triangle specific implementation
}
proc triangle::rotate {this angle} {
# triangle specific implementation
}
proc circle::circle {this x y} shape {$x $y} {
# derived from shape
# circle constructor implementation
}
proc circle::~circle {this} {}
proc circle::draw {this} {
# circle specific implementation
}
# circle rotate procedure is a noop, no need to overload
lappend shapes [new circle 20 20] [new triangle 80 20]
foreach object $shapes {
shape::draw $object
shape::rotate $object 45
}
eval delete $shapes
I have tried to make stooop Tcl code look like C++ code. There are exceptions of course.
A constructor is used to initialize an object of its class. The constructor is invoked by the new operator when an object of the class is created. The constructor is named as in C++ (for example, the shape constructor is named shape::shape).
The constructor always takes the object identifier (a unique value generated and returned by the operator new) as the first parameter, plus eventually additional parameters as in the normal Tcl proc command. Arguments with default values are allowed, and so are variable number of arguments (see below). In all cases, the first parameter must be named this.
Sample code of a class (with no base class) constructor:
proc shape::shape {this x y} {
# implementation here
}
If a class is derived from one or more base classes, the derived class constructor defines the base classes and their constructor arguments before the actual body of the constructor.
The derived class constructor parameters are followed by base class names / constructor arguments pairs. For each base class, there must be a corresponding list of constructor arguments to be used when the object is constructed by invoking the new operator on the derived class.
Sample code for a class constructor with a single base class:
proc circle::circle {this x y} shape {$x $y} {
# circle constructor implementation
}
proc hydroplane::hydroplane {this wingspan length} plane {
$wingspan $length
} boat {
$length
{
# constructor implementation
}
The base class constructor arguments must be prefixed with dollar-signs since they will be evaluated at the time the object is constructed, right before the base class constructor is invoked. This technique allows, as in C++, some actual processing to be done on the base class arguments at construction time. The this argument to the base class constructor must not be specified for it is automatically generated by stooop.
Sample code for a derived class constructor with base class constructor arguments processing:
proc circle::circle {this x y} shape {
[expr round($x)] [expr round($y)]
} {
# constructor implementation
}
The base class(es) constructor(s) is(are) automatically invoked before the derived class constructor body is evaluated. Thus layered object construction occurs in the same order as in C++.
Variable length arguments are a special case and depend on both the derived class constructor arguments and those of the base class.
If both derived and base class constructors take a variable number of arguments (through the args special argument (see proc manual page)), the base class constructor will also see the variable arguments part as separate arguments. In other words, the following works as expected:
proc base::base {this parameter args} {
array set options $args
}
proc derived::derived {this parameter args} base {
$parameter $args
} {}
new derived someData -option value -otherOption otherValue
The destructor is used to clean up an object before it is removed from memory. The destructor is invoked by the delete operator when an object of the class is deleted. The destructor is named as in C++ (for example, the shape constructor is named shape::~shape).
The destructor always takes the object identifier (a unique value generated and returned by the operator new) as the only parameter,which must be named this.
The base class(es) destructor(s) is(are) invoked at the end of the derived class destructor body. Thus layered object destruction occurs in the same order as in C++.
Sample code of a class destructor:
proc shape::~shape {this} {
# implementation here
}
Contrary to C++, a destructor cannot (nor does it need to) be virtual. Even if it does nothing, a destructor must always be defined.
A non-static member procedure performs some action on an object of a class. The member procedure is named as a member function in C++ (for example, the shape class move member procedure is named shape::move).
The member procedure always takes the object identifier (a unique value generated and returned by the operator new) as the first parameter, plus eventually additional parameters as in the normal Tcl proc command. Arguments with default values are allowed, and so are variable number of arguments. In all cases, the first parameter must be named this.
Sample code of a member procedure:
proc shape::move {this x y} {
set shape($this,x) $x
set shape($this,y) $y
# call another member procedure
shape::draw $this
}
A non-static member procedure may be a virtual procedure.
A static member procedure performs some action independently of the individual objects of a class. The member procedure is named as a member function in C++ (for example, the shape class add static member procedure is named shape::add).
However, with stooop, there is no static specifier: a member procedure is considered static if its first parameter is not named this. Arguments to the procedure are allowed as in the normal Tcl proc command. Arguments with default values are also allowed, and so are variable number of arguments.
Sample code of a static member procedure:
proc shape::add {newShape} {
# append new shape to global list of shape
lappend shape($shapes) $newShape
}
Often, static member procedures access static member data (see Non-static Member data).
A static member procedure may not be a virtual procedure.
If you never create objects by copying, you can skip this section.
The class copy constructor is optional as in C++. If it exists, it will be invoked when the operator new is invoked on an object of the class or a derived class.
The copy constructor takes 2 arguments: the this object identifier used to initialize the data members of the object to be copied to, and the copy identifier of the object to be copied from, as in:
proc plane::plane {this copy} {
set plane($this,wingspan) $plane($copy,wingspan)
set plane($this,length) $plane($copy,length)
set plane($this,engine) [new $plane($copy,engine)]
}
As in regular member procedures, the first parameter name must be this, whereas the second parameter must be named copy to differentiate from the class explicit constructor.
The copy constructor must be defined when the straightforward data members copy (see the new operator) is not sufficient, as in the example above. It is most often used when the class object contains sub-objects. As in C++ when sub-objects are referenced through their pointers, only the sub-object identifiers (see them as pointers) are copied when an object is cloned, not the objects they point to. It is then necessary to define a clone procedure that will initialize the object data members properly.
If the class has one or more base classes, then the copy constructor must pass arguments to the base class(es) constructor(s), just as the main constructor does, as in the following example:
proc ship::ship {this length} {}
proc carrier::carrier {this length} ship {$length} {}
proc carrier::carrier {this copy} ship {
$ship($copy,length)
} {
# copy all the planes
set ship($this,planes) {}
foreach plane $ship($copy,planes) {
lappend ship($this,planes) [new $plane]
}
}
The stooop library checks that the copy constructor properly initializes the base class(es) through its(their) constructor(s) by using the explicit constructor as reference.
All class and object data is stored in an associative array, the name of which is the name of the class. This class data array is at the global level. The proper global Tcl command is automatically inserted by stooop at the beginning of every class member procedure.
Within a class member procedure, one can access this class member data as well as all of its base classes data, no matter how far up in the base classes hierarchy.
Non-static data is indexed within the class array by prepending the object identifier (return value of the new operator) to the actual member name. A comma is used to separate the identifier and the member name.
Much as an object pointer in C++ is unique, the object identifier in stooop is also unique. Access to any base class data is thus possible by directly indexing the base class array.
Sample code:
proc shape::shape {this x y} {
set shape($this,x) $x
set shape($this,y) $y
}
proc circle::circle {this x y diameter} shape {$x $y} {
set circle($this,diameter) $diameter
}
proc circle::print {this} {
puts "circle $this data:"
puts "diameter: $circle($this,diameter)"
puts "coordinates: $shape($this,x), $shape($this,y)"
}
Static (as in C++) data members are simply stored without prepending the object identifier to the member name, as in:
proc shape::add {this newShape} {
# append new shape to global list of shape
lappend shape($shapes) $newShape
}
Only 3 new keywords new, delete and virtual need to be known in order to use stooop. Furthermore, their meaning should be obvious to C++ programmers. There is also a classof keyword that you can use if you need RTTI (runtime type identification).
The new operator is used to create an object of a class, either by explicit construction, or by copying an existing object.
When explicitly creating an object, the first argument is the class name and is followed by the arguments needed by the class constructor. New when invoked generates a new unique identifier for the object to be created. This identifier is the value of the this parameter, first argument to the class constructor, which is invoked by new.
Sample code:
proc shape::shape {this x y} {
set shape($this,x) $x
set shape($this,y) $y
}
set id [new shape 100 50]
# new generates a new id, say 1234
# shape constructor is then called, as in:
# shape::shape 1234 100 50
If the class is derived from one or more base classes, the base class(es) constructor(s) will be automatically called in the proper order, as in:
proc hydroplane::hydroplane {this wingspan length} plane {
$wingspan $length
} boat {
$length
} {}
set id [new hydroplane 10 7]
# new generates a new id, say 1234
# plane constructor is called, as in:
# plane::plane 1234 10 7
# then boat constructor is called, as in:
# boat::boat 1234 7
# finally hydroplane constructor is called, as in:
# hydroplane::hydroplane 1234 10 7
The new operator can also be used to copy objects when an object identifier is its only argument. A new object of the same class is then created, copy of the original object.
An object is copied by copying all its data members including member arrays (see Member array), starting from the base class layers. If the clone copy constructor procedure exists for any class layer, it is invoked by the new operator instead of the default data member copy procedure (see Copy constructor for examples).
Sample code:
set plane [new plane 100 57 RollsRoyce]
set planes [list $plane [new $plane] [new $plane]]
The delete operator is used to delete one or several objects. It takes one or more object identifiers as argument(s). Each object identifier is the value returned by new when the object was created. Delete invokes the class destructor for each object to be deleted.
Sample code:
proc shape::shape {this x y} {}
proc shape::~shape {this} {
proc triangle::triangle {this x y} shape {$x $y} {}
proc triangle::~triangle {this} {}
proc circle::circle {this x y} shape {$x $y} {}
proc circle::~circle {this} {}
set circleId [new circle 100 50]
# set circle identifier to, say 1234
set triangleId [new triangle 200 50]
# set triangle identifier to, say 1235
delete $circleId $triangleId
# delete circle object first
# circle destructor is invoked, as in:
# circle::~circle 1234
# then shape destructor is invoked, as in:
# shape::~shape 1234
# then delete triangle object
# ...
For each object class, if it is derived from one or more base classes, the base class(es) destructor(s) are automatically called in reverse order of the construction order for base class(es) constructor(s), as in C++.
The virtual specifier may be used on member procedures to achieve dynamic binding. A procedure in a base class can then be redefined (overloaded) in the derived class(es).
If the base class procedure is invoked on an object, it is actually the derived class procedure which is invoked, if it exists. If the base class procedure has no body, then it is considered to be a pure virtual and the derived class procedure is always invoked.
Sample code:
proc shape::shape {this x y} {}
# pure virtual draw: must be implemented in derived classes
virtual proc shape::draw {this}
virtual proc shape::move {this x y} {}
proc circle::circle {this x y} shape {$x $y} {}
proc circle::draw {this} {
# circle specific implementation
}
proc circle::move {this} {
# use base class implementation
::shape::move $this
# add circle specific implementation
}
lappend shapes [new circle 100 50]
foreach object $shapes {
# draw and move each shape
shape::draw $object
shape::move $object 20 10
}
It is possible to invoke a virtual procedure as a non virtual one, which is handy when the derived class procedure must use the base class procedure. In this case, calling the virtual base class procedure would result in an infinite loop. The non virtual base class procedure name is simply the virtual procedure name with 2 semi-columns prepended (see sample code above).
Constructors, destructors and static member procedures cannot be virtual.
The classof operator takes an object identifier as only argument. It returns the class name of the object (name used with new when the object was created). Thus if needed, RTTI (runtime type identification) can be used as in C++.
proc shape::shape {this x y} {}
set id [new shape 100 50]
puts "object $id class name is [classof $id]"
The new, delete and classof are also implemented in C for better performance. There is absolutely no difference (except speed) between the C and Tcl implementations. Sourcing the Stooop Tcl implementation is still required as only the time critical operations are implemented in C.
Sample code for Tcl 7.5:
# load extension first (preferred method but after also works)
load libstooop.so.2.1 stooop
source stooop.tcl
# your object oriented code here...
Tests show that performance increases by about 300% on the average for tiny objects, less with bigger objects as constructor and destructor Tcl code start prevailing. The use of the extension is recommended if you often copy and delete objects in your code, as those operations (especially the copy operation) are slow when implemented in pure Tcl.
Instructions on how to create the dynamically loadable library can be found in the C source file).
For C++ programmers, this simple parallel with C++ may make things easier to understand. First without virtual functions:
C++:
className::className(someType parameter)
{
someMember = parameter;
}
className::className(className &object)
{
...
}
className::~className(void)
{
...
}
someType className::doSomething(someType parameter)
{
...
}
className *someObject = new className(someValue);
someType a = someObject->doSomething(someValue);
someType b = someObject->someMember;
className *otherObject = new className(*someObject);
delete someObject;
Tcl:
proc className::className {this parameter} {
# new keeps track of object ids and passes a unique one to the
# constructor
set className($this,someMember) $parameter
}
proc className::className {this copy} {
# copy constructor
...
}
proc className::~className {this} {
# delete calls this procedure then take care of deallocating className
# array members for this id
...
}
proc className::doSomething {this parameter} {
...
}
set someObject [new className $someValue]
# invokes className::className
set a [className::doSomething $someObject $someValue]
set b $className($someObject,someMember)
# copy object, className::clone procedure is invoked
set otherObject [new $someObject]
delete $someObject
# invokes className::~className then frees members data
Now, with virtual functions:
C++:
class baseClassName {
public:
virtual void doSomething(someType);
baseClassName(void);
virtual ~baseClassName(void);
};
class derivedClassName: public baseClassName {
public:
void doSomething(someType);
derivedClassName(void);
~derivedClassName(void);
};
derivedClassName *someObject = new derivedClassName();
someObject->doSomething(someValue); // derived function actually called
cout << typeid(*someObject).name() << endl; // print object class name
delete someObject; // derived destructor called first
Tcl:
proc baseClassName::baseClassName {this} {
# sub-class is remembered so that virtual procedures may be used
# ...
}
proc baseClassName::~baseClassName {this} {
# cleanup at base level here...
}
virtual proc baseClassName::doSomething {this parameter} {
# derived class procedure with the same name may be called
# any code that follows is not executed if this procedure is
# overloaded in derived class
# ...
}
proc derivedClassName::derivedClassName {this} baseClassName {} {
# base class constructor is automatically evaluated
# ...
}
proc derivedClassName::~derivedClassName {this} {
# cleanup at derived level here...
# base class destructor is automatically evaluated
}
proc derivedClassName::doSomething {this parameter} {
# code that follows is executed when base class procedure is called
# ...
}
set someObject [new derivedClassName]
# access object as a base object but derived class procedure actually called
baseClassName::doSomething $someObject $someValue
# print object class name
puts [classof someObject]
# delete object
delete $someObject
A demonstration using the Composite pattern from the great book Design Patterns, Elements of Reusable Object-Oriented Software, which I heartily recommend.
The pattern is used to define a class hierarchy of the graphic base class, picture, oval and rectangle derived classes. A picture object can contain any number of other graphic objects, thus allowing graphical composition.
The following paragraphs drawn from the book best describe what the Composite pattern does:
Compose objects into tree structures to represent part-whole hierarchies. Composite lets clients treat individual objects and compositions of objects uniformly.
The key to the Composite pattern is an abstract class that represents both primitives and their containers. For the graphic system, this class is Graphic. Graphic declares operations like Draw that are specific to graphical objects. It also declares operations that all composite objects share, such as operations for accessing and managing its children.
Gamma/Helm/Johnson/Vlissides, DESIGN PATTERNS, ELEMENTS OF REUSABLE OBJECT-ORIENTED SOFTWARE, (c) 1995 by Addison-Wesley Publishing Company, Reprinted by permission of Addison-Wesley Publishing Company, Inc.
A widget usually can take a variable number of option / value pairs as arguments when created and any time later when configured. It is a good application for the variable number of arguments technique.
Sample code:
proc widget::widget {this parent args} {
# create Tk widget(s)
# set widget options default in an array
array set options {-background white -width 10}
# then overwrite with user options
array set options $args
# then configure
eval ::widget::configure $this [array get options]
}
virtual proc widget::configure {this args} {
# parse options here
array set value $args
foreach option [array names value] {
switch -- $option {
# filter widget specific options here
-background {
set widget($this,background) $value($option)
# configure Tk widget(s)
}
# ...
}
}
}
proc gizmo::gizmo {this parent args} widget {$parent $args} {
# create more Tk widget(s)
# set gizmo options default in an array
array set options {-spacetimecoordinates {0 0 0 now}}
# then overwrite with user options
array set options $args
# then configure
eval gizmo::ownConfigure $this [array get options]
}
proc gizmo::ownConfigure {this args} {
# parse options here
array set value $args
foreach option [array names value] {
switch -- $option {
# filter gizmo specific options here
-spacetimecoordinates {
set gizmo($this,location) $value($option)
# configure Tk widget(s)
}
}
}
}
proc gizmo::configure {this args} {
# configure at gizmo level
eval gizmo::ownConfigure $this $args
# configure at widget level
eval ::widget::configure $this $args
}
new gizmo . -width 20 -spacetimecoordinates {1p 10ly 2p 24.2y}
In this example, invalid (unknown) options are simply ignored.
You simply cannot use a member array, as member data is already held in an array. But you can use a global array, with a name specific to the object, including the object identifier. Just make sure the array is deleted in the destructor.
Sample code:
proc container::container {this} {}
proc container::~container {this} {
global container${this}data
unset container${this}data
}
proc container::add {this item id} {
global container${this}data
set container${this}data($id) $item
}
If you use the class${this}array name syntax for the member array name, then the array will be automatically copied as other data members during the cloning operation (see new operator).
Performance would have to as good as possible.
A familiar C++ syntax should serve as a model (not all, though, I didn't feel like writing 700 pages of documentation :-).
Tcl being a non-declarative language (which I really enjoy), stooop would have to try to comply with that approach.
Error checking would have to be strong with little impact on performance.
For a Tcl only extension, I think performance is the main issue. The performance / functionality compromise was handled by moving as much processing as possible to the preprocessing stage, handled by the proc and virtual commands. Furthermore, all the costly error checking could be done there as well, having no impact on runtime performance.
The delete operation was greatly simplified, especially for classes that would require a virtual destructor in C++, by storing in an array the class of each object. It then became trivial to delete any object from its identifier only. This approach has an impact on memory use, though, but I consider that one is not very likely to create a huge number of objects in a Tcl application. Furthermore, a new classof RTTI operator was added with no effort.
stooop learns class hierarchies through the constructor definition which serves as an implementation as well, thus (kind of) better fitting the non-declarative nature of Tcl.
All member data is public but access control is kind of enforced by having to explicitely name the class layer (array name) that the data belongs to. Similarly, to access another object data from a different class member procedure, one has to declare that other class as global first in order to do so.
If you benchmark stooop against itcl or some other object extension, please mail me the results. I will compare with itcl when it becomes available for Tcl 7.4/7.5.
For a Tcl class browser for stooop code that can generate a HTML document from source code please mail below.
Send your comments, complaints, ... to
Jean-Luc Fontaine