The [TCL Architecture of Objects]

Not to be confused with Tao (S), the ever changing state of the Universe, or [The Tao of Tcl].

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.

'''Quick Links'''

   * Main Website [http://www.etoyoc.com/tao/]
   * Download [http://www.etoyoc.com/tao/download]
   * Development Manual [http://www.etoyoc.com/tao/download/TaoManual.pdf]
   * Live snapshot of code from a running server [http://www.etoyoc.com/tao/snapshot/]

'''Tao Modules'''

Each of the modules is packaged as a tarbal 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+

   * core - The main object engine
   * llama - A UI engine for simultaneous development of HTML, LaTeX, an Tk pressentations
   * taodbi - A general purpose interface to databases systems
   * taourl - An object oriented web development kit

----
'''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, it's 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?'''

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 your call the 'hello' method of object 'fubar'.

 set obj [::tao::object fubar-1] 
 $obj hello

What 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.  

----
[[[Category Acronym]|[Category Glossary]|[Category Object Orientation]]]