The TCL Architecture of Objects Version 1.0
(The code that can be coded is not the true code, this is a discussion of an older version of Tao. Current development can be discussed at TAO)
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 9.0 Tao uses the TclOO extension to implement classes and methods inside of Tcl. Tao created classes are inheritable by TclOO classes. I'm working on the reverse. Tao methods don't "require" the "my" call for local methods, but it's recommended. Tao also exports all methods by default, but as my libraries mature they will adopts the TIP 257 convention of method starting with a lower case are exported while upper case are considered "private."
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
(Some of this is out of date, and in the process of being updated for Tao 9.0)
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?
Well it used to be about multiple inheritance. But as Tao has evolved, it has emerged as a light-weight object system on its own merits. The rules of TAO are designed to make behavior predictable for very large, complex, and otherwise nasty class hierarchies.
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. (This was as of 2002).
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. 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.
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-compatible.
(Postscript for Tao 9.0: Tao is actually implemented on top of TclOO. Much to the merriment of myself AND Donal.)