The TCL Architecture of Objects
Not to be confused with Tao (S), the ever changing state of the Universe, The Tao of Tcl, or The Ace Orb (TAO) [L1 ], which uses a feather icon on their web site.
Documentation and download: http://www.etoyoc.com/tao/
TAO is a programming architecture for the TCL programming language. It can could be described as yet another object system for TCL, but in reality it is a methodology for open ended program design.
With version 8.5.0 Tao is now pure Tcl code, at the expense of requiring Tcl 8.5.
Quick Links
Tao Modules
Each of the modules is packaged as a tarball that can be unpacked into your auto_path. They are self-contained with a copy of the core and all supporting libraries (save the biggies like tcllib). Tao's only external requirements are sqlite3, tcllib, and tcl8.4+ .
Introduction to TAO Programming
(For a full tour of the system, please see the development guide.)
TAO tries very much to look like Incr Tcl. This is by design, as it was intended to port a large library of existing Incr Tcl code with a minumum of fuss. So before we get too far, why would one decide to use TAO over Incr Tcl? It comes down to multiple inheritence. While Incr Tcl does support it, its concept is quite primitive when it comes to dealing with multiple decendents from a common ancestor.
Say you have "The mother of all Classes", class MOAC. In a database system you go off and implement a pile of creature comforts that you want all objects to possess. But what if you decide later to fuse two decendents of MOAC? You're screwed. Incr Tcl will throw up and die because it doesn't want to be bothered sorting out how much of this and how much of that go into a particular class. Each class can be inherited once and only once.
After knocking my head for years with different schemes to fit into this straightjacket of a concept, I realized there had to be a better way. So I wrote one. The answer was to stop thinking of classes as data structures, and instead to think of them as the product of a database search. (Thus the dependency on sqlite.) When one builds the spec for a class, you really aren't doing anything but loading data into a central corpus. It is only when an object is called into being that the final decisions are made about the form and structure of a class, the content of the method bodies, etc.
How does it do that?
Main discussion and code: Tao Data Encapsulation
Keep track of private variables? Methods are never called directly. They are run through a wrapper function, which loads a preamble for an object. The preamble links local variables to global places where the object state is stored. The method calls also take place inside a namespace where the rest of the methods for a class are implemented, allowing a method to call other methods from the same class. How do the subcalls keep track of the object if all the objects from the same class use the same namespace? A stack of course!
Say you call the 'hello' method of object 'fubar'.
::tao::class ::hello {
inherit ::tao::root
method hello {} {
return Hello
}
}
::tao::new ::hello theObj
theObj hello
> HelloWhat does $obj do? It isn't actually the object. It's a procedure that pushes 'fubar-1' onto the stack, and then makes a call to the namespace that implements it. Every method in the class namespace is a procedure that, before it does anything else, loads the local environment for the object on the top of the stack.
Let's take a look inside:
info body ::theObj > return [::tao::object_method_invoke ::hello ::theObj $method $args]
The "object" handle is really just a proc that calls into a namespace defined by the class. To handle multiple objects, we put a little preamble on all the methods:
info body ::hello::hello > ::tao::peek > return Hello
object_method_invoke pushes ::theObj onto the execution stack, ::tao::peek reads that and loads the local environment for ::theObj.
Discussion
RLH I am just curious...does this use any of the OO stuff that is going into 8.5 or is it "your" object system? If so, why did you go this route? Do not take it as a critique at all as it seems cool. Just want to get into your head about the rationale.
SDW: Yes it's my system. That said, because the code is fed into a database and assembled on the fly there is nothing that is keeping it from exploiting the new TclOO features as they come on line. TclOO is not intended to be an object system by itself, it is (or will be) a set of tools for implementing one. I have a ranting about "Why" that I've posted on my blog to save space on this page: [L7 ]
LV: Is this statement (that tcloo is not intended to be an object system) still true? The debates and discussions I've been reading over the past 7+ months seemed, to me, to indicate otherwise. However, I've been trying to locate these discussions (which centered around questions being answered by DKF, who is responsible for the majority (perhaps all) of the OO code being developed for the tcl core. If someone locates those discussions, this would be a fine place to plug them in.
SDW: From the Tcl'ers Chat on 2007-08-01
[10:38] hypnotoad Donal, there was a question about the nature of TclOO. My recollection
was that it was more a framework for rolling one's own OO. Others disagree.
[10:38] dkf I think it's a framework
[10:38] dkf but it's also capable enough on its own, provided you don't want a lot of fancy variable handline
[10:38] dkf handlingSo methinks the answer to whether TclOO is a framework or a Object System is "yes". Getting back to the discussion Tao isn't about the implementation. It's about a notation scheme and set of predicatable behaviors that will make code developed today forward-compadible.
[Category Acronym|Category Glossary|Category Object Orientation]