Object Oriented Programming in Tcl

The core of OO programming is, no surprise, an object. An object, often a representation of some real world entity, captures state (data) and behaviour which is the object’s response to messages sent to it. In most languages, implementation of these messages involves calling methods which are just function calls with a context associated with the object. For example, the state contained in an object representing a bank account would include items such as the current balance and account number. The object would respond to messages to deposit or withdraw funds.

A class is (loosely speaking) a template that defines the data items and methods (collectively called members) encapsulated by objects of a specific type. More often than not, creating a object of the class, often known as instantiating an object, is one of the duties of the class.

Not every OO system has, or needs, the notion of a class. Prototype based systems instead create objects by “cloning” an existing object - the prototype - and defining or modifying members.

TclOO provides facilities to support both the classy and the classless^[1] models.

Classes are created in TclOO using the oo::class create command. Let us create a class, Account, that models a banking account.

This creates a new class Account that can be used to create objects representing bank accounts.

There is however no class definition associated with our Account class and therefore, there is as yet no state or behaviour defined for objects of the class. That is done through one or more class definition scripts. We will look at the contents of these definition scripts throughout this chapter, but for now, simply note that class definitions can be built up in incremental fashion. A definition script can be passed as an additional argument to the oo::class create command, in the form

and also through one or more oo::define commands which take the form

Thus the statements

and

are equivalent.

We will see both forms of class definition as we go along. As is generally the case, Tcl has the flexibility to fit your programming style.

A class, as we shall see later, is also an object and like all objects can be destroyed.

This will erase

Not commonly used in operational code, this ability to destroy classes is sometimes useful during interactive development and debugging to reset to a known clean state.

We will be using the Account class throughout the chapter so let us recreate it before we move on.

In our simple example, the state for an account object includes an account number that uniquely identifies it and the current balance.

We will need data members to hold this information and we define them through a class definition script passed to oo::define.

This defines the data members for the class as per-object variables. AccountNumber and Balance are then visible within all methods of the class and can be referenced there without any qualifiers or declarations.

There can be multiple variable statements, each defining one or more data members.

Data members do not have to be declared using variable in a class definition script. They can also be declared within a method using the my variable command which we show later.

Having defined the data members, let us move on to defining the methods that comprise the behaviour of an Account object. An Account object responds to requests to get the current balance and to requests for depositing and withdrawing funds.

Methods are defined through the method command which, like variable, is executed as part of a class definition script.

As you see, a method is defined in exactly the same manner as proc defines a Tcl procedure. Just like in that case a method takes an arbitrary number of arguments including a variable number of trailing arguments collected as the args variable. The difference from a procedure lies in how it is invoked and the context in which the method executes.

A method runs in the context of its object’s namespace. This means the object data members such as Balance, defined through variable, are in the scope of the method and can directly be referenced without any qualifiers as seen in the method definition above.

The method context also makes available several commands - such as self, next and my - which can only be called from within a method. We will see these as we proceed with our example but for now note the use of my to refer to a method of the object in whose context the current method is running.

Another point about method definitions concerns method visibility. An exported method is a method that can be invoked from outside the object’s context. A private method on the other hand, can only be invoked from within another method in the object context. Methods that begin with a lower case letter are exported by default. Thus in our example, deposit and withdraw are exported methods while UpdateBalance is not. Method visibility can be changed by using the export and unexport commands inside a oo::define class definition script. Thus

would result in UpdateBalance being exported as well.

Method definitions can be deleted at any time with the deletemethod command inside a class definition script.

Deletion of methods from classes is rarely used. However, deletion of methods from objects is sometimes useful in specialization of objects.

There is one final thing we need to do before we can start banking operations and that is to provide some means to initialize an Account object when it is created and perform any required clean up when it is destroyed.

These tasks are performed through the special methods named constructor and destructor. These differ from normal methods in only two respects:

For our simple example, these methods are straightforward.

Both constructors and destructors are optional. They do not have to be defined in which case TclOO will simply generate empty methods for them.

Every object has a method named unknown which is run when no method of that name is defined for that object (actually in the method chain for that object as we see later).

The definition of the unknown method takes the form

The unknown method is passed the name of the invoked method as its first argument followed by the arguments from the invocation call.

The default implementation of this method, which is inherited by all objects from the root oo::object object, raises an error. Classes and objects can override the default implementation method to take some other action instead.

An example of its use is seen in the COM client implementation in TWAPI. The properties and methods exported from a COM component are not always known beforehand and in fact can be dynamically modified. The TclOO-based wrapper for COM objects defines an unknown method that looks up method names supported by a COM component the first time a method is invoked. If found, the lookup returns an index into a function table that can then be invoked through the ComCall method. The implementation of unknown looks like

(This is a greatly simplified, not entirely accurate or correct, description for illustrative purposes.)

As we have seen in previous sections, you can incrementally modify a class using oo::define. Practically nothing about a class is sacred - you can add or delete methods, data members, change superclasses or mixins, and so on.

The question then arises as to what happens to objects that have already been created if a class is modified. The answer is that existing objects automatically “see” the modified class definition so for example any new methods can be invoked on them. Or if you add a mixin or a superclass, the method lookup sequence for the object will be appropriately modified.

However some care should be taken when modifying a class since existing objects may not hold all state expected by the new class. For example, the new constructors are (obviously) not run for the existing objects and thus some data members may be uninitialized. The modified class code has to account for such cases.

An object of a class is created by invoking one of two built-in methods on the class itself. The create method creates an object with a specific name. The new method generates a name for the created object.

Creating an object also initializes the object by invoking a its constructor.

The created objects are Tcl commands and as such can be created in any namespace.

Note that my_account and my_ns::my_account are two distinct objects.

Objects in Tcl are not garbage collected as in some other languages and have to be explicitly destroyed by calling their built-in destroy method. This also runs the object’s destructor method.

Any operation on a destroyed object will naturally result in an error.

Objects are also destroyed when its class or containing namespace is destroyed. Thus

generates an error as expected.

An object in Tcl behaves like an ensemble command of the form

This is the form used to invoke a method on the object from code “outside” the object.

As discussed earlier, when calling a method from another method in the same object context, the alias my is used to refer to the current object. So the deposit method we saw earlier calls the UpdateBalance method as:

Data members are not directly accessible from outside the object. Methods, such as balance in our example, have to be defined to allow callers to read and modify their values. Many OO-purists, and even non-purists like the author, believe this to be desirable.

However, Tcl being Tcl, it is always possible to add a variable access capability using the fact that each object has a private namespace that can be retrieved through introspection. Thus,

This practice breaks encapsulation and is not recommended. However, some OO systems layered on top of TclOO do offer this feature in a structured manner that does not explicitly expose internal object namespaces. These are however not discussed here.

A good alternative is to automatically define accessor methods for public variables without the programmer having to explicitly do so. One such implementation is described in the Lifecycle Object Generators paper.

Methods available in the base class are available in derived classes as well. In addition, new methods can be defined such as cash_check and the monthly_update in our example, that are only present on objects of the derived class.

If the derived class defines a method of the same as a method in the base class, it overrides the latter and will be called when the method is invoked on an object of the derived class. Thus the withdraw method of the SavingsAccount class overrides the withdraw method of the base Account class. However, we are just modifying the original method’s functionality with an additional condition, not replacing it. Therefore, after making the check we want to just pass on the request to the base class method and not duplicate its code. This is done with the command next which invokes the next method in the which in this case is the superclass method with the same name as the current method. This method chaining is actually only an example of broader mechanism we will explore in detail later.

Constructors and destructors are also chained. If a derived class does not define a constructor, as is true for the CheckingAccount class, the base class constructor is invoked when the object is created. If the derived class does define a constructor, that is invoked instead and it is up to that constructor to call the base class constructor using next as appropriate. Destructors behave in a similar fashion.

Note that next may be called at any point in the method, not necessarily in the beginning or the end.

Derived classes can define new data members using either variable in the class definition or my variable within a method as in withdraw.

Data members defined in a parent (or ancestor) class are also accessible within a derived class but they have to be brought within scope of the method through the variable declaration in the derived class definition or the my variable statement within a method as is done in the implementation of monthly_update. Although we use a direct variable reference there for expository purposes, in the interest of data hiding and encapsulation, direct reference to variables defined in ancestors should be avoided if possible. It would have been better to write the statement as

Let us try out our new accounts.

Imagine our bank is actually a full financial services firm that also provides stock trading services. Accordingly we have a class corresponding to a brokerage account.

The company now decides to make it even more convenient for customers to lose money participate in the stock market. So we come up with a new type of account, a Cash Management Account (CMA), which combines the features of the checking and brokerage accounts. We can model this in our system using multiple inheritance, where the corresponding class inherits from more than one parent class.

Our CMA account can do it all.

Use of multiple inheritance is a somewhat controversial topic in OO circles. Be as it may, TclOO offers the facility, and also an alternative using mixins, and leaves the design choices for programmers to make. As it should be.

Let us illustrate with our banking example. Imagine our banking system had the requirement that individual accounts can be frozen based on an order from the tax authorities. We need to define a procedure we can call to freeze an account so all transactions on the account will be denied. Correspondingly, we need a way to unfreeze an frozen account. The following code accomplishes this.

When the freeze procedure is passed an Account object, it uses oo::objdefine to override the UpdateBalance method that was part of the object’s class definition with a object specific UpdateBalance method that raises an error instead.

It then defines a new method unfreeze that can be called on the object at the appropriate time to restore things back to normal. We could have actually defined an unfreeze procedure instead of a unfreeze method as follows:

This would have accomplished the same job in a clearer manner. We chose to implement an unfreeze method instead to illustrate that we can actually change an object’s definition even from within the object.

There are a couple of points that need to be elaborated:

Let us see how all this works. At present Mr. Smith can withdraw money freely from his account.

So far so good. Now we get a court order to freeze Mr. Smith’s account.

Mr. Smith tries to withdraw money and run away to the Bahamas.

Have we affected other customers?

No, only the smith_account object was impacted.

Cornered Mr. Smith pays up to unfreeze the account.

This ability to define object-specific methods can be very useful. Imagine writing a computer game where the characters are modeled as objects. Several characteristics of the objects, such as the physics determining movement, are common and can be encapsulated with a class definition. The special “powers” of each character cannot be part of this class and defining a separate class for each character is tedious overkill. The special power of a character can instead be added to the character’s object as a object-specific method. Even modeling scenarios like temporary loss of a power without a whole lot of conditionals and bookkeeping becomes very simple using the object specialization mechanisms.

Being a true dynamic OO language, TclOO can even change the class of an object through oo::objdefine. For example, one might change a savings account to a checking account.

So far so good. Let us attempt to cash a check.

Naturally that fails because it is not a checking account. Not a problem, we can fix that by morphing the object to a CheckingAccount.

We can now cash checks successfully

but monthly updates no longer work as the account is no longer a SavingsAccount.

Needless to say, you have to be careful when “morphing” objects in this fashion since data members may differ between the two classes.

Lifecycle Object Generators describes an example of when such morphing might be used. Consider a state machine where each state is represented by a class that implements the state’s behaviour. When a state change occurs, the state machine object changes its class to the class corresponding to the target state. See the abovementioned reference for implementation details.

A class or object may have multiple classes mixed in. So for example if we had a facility for electronic bill presentment implemented as a mixin class BillPay, we could have added it along with EFT as a mixin in a single statement

or as multiple statements

Because one of its goal is to provide the required infrastructure for additional OO system to be built on top, TclOO offers a wide variety of capabilities that sometimes overlap in their effect. The question then arises as to how to choose the appropriate feature for a particular design requirement. One of these design choices involves mixins and inheritance.

We offer the author’s thoughts on the matter. Luckily, these tend to be few and far between so a couple of paragraphs is sufficient for this purpose.

Instead of mixing our EFT class into CheckingAccount, we could have made it a superclass and used multiple inheritance instead. Or even modified or derived from the CheckingAccount class to add transfer methods. Why did we choose to go the mixin route?

Not directly inheriting or modifying the CheckingAccount class was a no-brainer for obvious reasons. The functionality is something that could be used for other account types as well and it does not make sense to duplicate code and add it to every class that needs those features. That leaves the question of multiple inheritance.

There were several considerations:

For these reasons, mixins seemed a better choice in our design (aside from the fact that we needed some example to illustrate mixins).

There is one practical aspect of TclOO design that may drive your decision. Methods implemented via mix-ins appear in the method chain before methods defined on the object whereas inherited methods appear after. This was not relevant to our example because the mix-in only added new methods. It did not override exising ones.

The filter declaration need not occur in the same class that defines the filter method. This means you can define a generic class for a filter which can be mixed into a “client” class or object which can install or remove the filter at appropriate times as desired.

Let us rework our previous example. To start with a clean slate, let us get rid of the Log method we defined on the object earlier.

Then we define a class that does the logging.

Since we only want transactions for that account to be logged, we then mix it into the object and add the filter declaration.

As you can see, we have the same behaviour as before. The advantage of course is that defining a class allows a collection of additional behaviours to be abstracted and easily added to any class or object without repeating the code.

Filters could be replaced by other techniques such as overriding and then chaining methods. Conversely, method overrides, such as in our account freeze example, could be replaced by filters. Usually though it is clear which one makes the most sense. Some general rules are

For the exact search order and construction of this method chain, see the reference documentation of the next command. Here we will simply illustrate with an example where we define a class hierarchy with multiple inheritance, mixins, filters and object-specific methods. Note our method definitions are empty because we are not actually going to call them.

We have created an object of class Derived that inherits from two parent classes, all of which define a method m. Further we have mixins for both a class and directly into the object. To confuse matters further, we have filters defined at both the class and object levels.

What will the method chain for method m look like? Luckily, we do not have to work it out while reading the manpage. We can do it through introspection via the info object call command.

The output shows the method chain so we can see for example that the filter methods are first in line.

The info object call command returns a list that contains the method chain for a particular method invocation for a particular object. Each element of the list is a sublist with four items:

We reiterate that not every method in the chain is automatically invoked. Whether a method occuring in the list is actually called or not will depend on preceding methods passing on the invocation via the next command.

What does the method chain look like for a method that is not defined for the object? We can find out the same way.

As expected, the unknown methods, where defined, are called. Note the root oo::object object which is the ancestor of all TclOO objects, has a predefined unknown method.

The above example showed the method chain for an object. There is also a info class call command that works with classes instead of objects.

Within a method context, the command self call returns more or less the same information for the current object as info object call.

In addition, you can use self call from within a method context to locate the current method in the method chain. This command returns a pair, the first element of which is the same as the method chain list as returned by info class call command. The second element is the index of the current method in that list.

An example will make this clearer.

Note the special form <constructor> for constructors. Destructors similarly have the form <destructor>.

At times a method implementation may wish to know if it is the last method in a method chain and if not, what method implementation will be invoked next. This information can be obtained with the self next command from within a method context.

We illustrate by modifying the m method of the Derived class that we just defined.

As seen, self next returns a pair containing the class or object implementing the next method in the method chain and the name of the method (which may be <constructor> and <destructor>). In the case the current method is the last in the chain, an empty list is returned.

Notice that although the next method in the method chain is printed out, it does not actually get invoked because the m method in Derived no longer calls next.

There is one important issue solved by self next that we will illustrate with an example. Imagine we want to package some functionality as a mixin class. The actual functionality is immaterial but it is intended to be fairly general purpose (for example, logging or tracing) and mixable into any class.

So far so good. Now let us define another class that also uses the mixin.

Oops. What happened? If it is not clear from the error message, the issue is that the GeneralPurposeMixin class naturally calls next so that class that mixes it in can get initialized through its constructor. The error is raised because class MixerB does not have constructor so there is no “next” method (constructor) to call.

This is where self next can help. Let us redefine the constructor for GeneralPurposeMixin.

Voila! It all works now because we only call next if there is in fact a next method to call.

As we have seen in our examples, a method can use the next command to invoke its successor in the method chain. With multiple inheritance, mixins, filters involved, it may sometimes be necessary to control the order in which inherited methods are called. The next command, which goes strictly by the order in the method chain, is not suitable in this case.

The nextto command allows this control. It is similar to the next except that it takes as its first parameter the name of the class that implements the next method to be called.

Here CLASSNAME must be the name of a class that implements a method appearing later in the method chain.

When might you use this ? Well, imagine you define a class that inherits from two classes whose constructors take different arguments. How do you call the base constructors from the derived class? Using next would not work because the parent class constructors do not take the same arguments.

That’s where nextto rides to the rescue as illustrated below.

We can now call it without conflicts.

The info class instances command returns a list of objects belonging to the specified class.

As seen above, this command will only return objects that directly belong to the specified class, not if the class membership is inherited.

You can optionally specify a pattern argument in which case only objects whose names match the pattern using the rules of the string match command are returned. This can be useful for example when namespaces are used to segregate objects.

Classes are also objects in TclOO and therefore the same command used to enumerate objects can be used to enumerate classes.

We pass oo::class to the command because that is the class that all classes (or class objects, if you prefer) belong to. The returned list contains two interesting elements:

As before, we can also restrict the classes returned by specifying a pattern that the name must match.

The info class superclasses command returns the direct superclasses of a class.

Notice that oo::object is a superclass of oo::class.

Conversely, the info class subclasses will return the classes directly inheriting from the specified class.

As one might expect, there is also a command, info class mixins for listing mixins.

You can get the class an object belongs to with info object class.

The same command will also let you check whether the object belongs to a class, taking inheritance into account.

For enumerating the classes mixed-in with an object, use info object mixins, analogous to info class mixins.

From within the method context of an object, the command self class command returns the class defining the currently executing method. Note this is not the same as the class the object belongs to as the example below shows.

The list of methods implemented by a class or object can be retrieved through info class methods and info object methods respectively. Options can be specified to control whether the list includes inherited and private methods.

The list of methods that are set as filters can similarly be obtained with info class filters or info object filters.

To retrieve the definition of a specific method, use info class definition. This returns a pair consisting of the method’s arguments and its body.

The method whose definition is being retrieved has to be defined in the specified class, not in an ancestor or a class that is mixed into the specified class.

Constructors and destructors are retrieved differently via info class constructor and info class destructor respectively.

The info class call command retrieves the method chain for a method. From a method context, the self call command returns similar information while self next identifies the next method implementation in the chain.

We have already discussed all these in detail in an earlier section.

When a method is run as a filter, it is often useful for it to know the real target method being invoked. This information is returned by self target which can only be used from within a filter context. Its return value is a pair containing the declarer of the method and the target method name.

For example, suppose instead of logging every transaction as in our earlier example, we only wanted to log withdrawals. In that case we could have defined the Log command as follows:

We would now expect only withdrawals to be logged.

We are 100% right. Again!

The other piece of information that is provided inside a filter method is about the filter itself and is available through the self filter command.

Let us redefine our Log filter yet again to see this.

As seen above, the self filter command returns a list of three items:

Under some circumstances, an object needs to discover its own identity from within its own method context.

An object can be identified in two ways:

The former is returned by the self object command, which can also be called as simply self. A method may need to know command name of the object

See Object-specific methods for an example.

The unique namespace associated with the object is obtained through the self namespace command within a method context or with the info object namespace command elsewhere.

Notice when we create an object using new the namespace matches the object command name. This is an artifact of the implementation and this should not be relied on. In fact, like any other Tcl command, the object command can be renamed.

As you can see, the object command and its namespace name no longer match. Also note the namespace does not change when the command is renamed.

The command info class variables returns the list of variables that have been declared with the variable statement inside a class definition and are therefore automatically brought within the scope of the class’s methods.

The listed variables are only those defined through the variable statement for that specified class. Thus the above command will not show the variable Balance as that was defined in the base class Account, not in SavingsAccount.

For enumerating variables for an object as opposed to a class, there are two commands:

Hence the difference between the output of the following two commands.

The first command returns an empty list because no variables were declared through variable for that object. The second command returns the variables in the object’s namespace. The fact that they were defined through a class-level declaration is irrelevant.