This is not necessarily the current version of this TIP.This is not necessarily the current version of this TIP.
| TIP: | 279 |
| Title: | Adding an Extensible Object System to the Core |
| Version: | $Revision: 1.4 $ |
| Author: | Gustaf Neumann <neumann at wu-wien dot ac dot at> |
| State: | Draft |
| Type: | Project |
| Tcl-Version: | 8.5 |
| Vote: | Pending |
| Created: | Thursday, 05 October 2006 |
This TIP proposes adding OO support to the Tcl core, consisting mostly of an dispatcher plus a small number of helper commands. The TIP allows the coexsitance of multiple object systems by providing a common framework, the Tcl Minimal Object System (TMOS). The framework will contain as well a small basic oriented language (Tcl Core Object Oriented Language, TclCOOL) to make it useable in the core without any extensions. All defined commands of the minimal object system are defined in the ::oo namespace, which is not used by any current mainstream OO system. It will designed specifically to allow a relative simple re-implementation of the known object systems.
Rather than proposing any kind of OO language, the TIP suggests to add a framework to the core, that many existing and future extensions (including XOTcl) can use. This framework alone is not useful as an OO language, but is an environment that can host multiple OO languages in parallel, such as Snit or XOTcl (maybe the language from current TIP #257 as well), without pushing a single model. Languages like Snit or XOTcl can continue to develop, the core developers can optimize and integrate better with the tcl-core, etc.
The framework (Tcl Minimal Object System, TMOS) consists of an flexible object interpreter (dispatcher) able to run the most powerful current object extensions. This dispatcher is accompanied by a "minimal object system" and a small set of predefined, but unattached methods (basic method set) and an "extension mechanism". For the bootstrapping of different object systems, only a single method for allocating objects or classes is proposed, plus a few commands for setting up the object/class relations and registering methods.
The Tcl Minimal Object System is used for the definition of TclCOOL (Tcl Core Object Oriented Language). TclCOOL is simple but powerful object language realized with TMOS.
Additional object systems (like XOTcl, SNIT or STOOP) can be loaded as an extensions (being not part of the core), and can provide their own method-sets (or re-use the predefined method set, or reuse the methods-set of some extension).
This approach provides a flexibility much higher than in other popular scripting languages and lets object systems designer continue to improve their work based on Tcl.
The minimal object system consists of a base class (::oo::object) and a meta-class (::oo::class, subclass of ::oo::object).
name of class kind of class superclass instance-of ========================================================== ::oo::object class ::oo::object ::oo::class ::oo::class meta-class ::oo::object ::oo::class
The meta-class ::oo::class has two methods named "alloc" and "dealloc" (names are arbitrary, as shown later) to create objects or classes. ::oo::object has no methods at all.
The minimal object system is intended to be specialized by one or more different object systems. An object system is created by sub-classing the base classes configuring these according to the object systems needs. This configuration consists of defining its relations to the general base and meta-class, and equipping these extension specific classes with additional functionality (providing methods). The whole configuration of the object system can be done completely from the scripting level.
The minimal object system defines the following commands and methods in the ::oo namespace:
Two classes
::oo::class ::oo::object
Two unexported Tcl commands for OO-language designer
::oo::alias ::oo::setrelation
Three exported Tcl commands to be used by in the languages
::oo::my ::oo::self ::oo::next
An unregistered (unattached) set of methods that can be used for classes
alloc, dealloc, instproc, instforward, info
An unregistered (unattached) set of methods that can be used to objects | instvar forward info
The Tcl command ::oo::setrelation
::oo::setrelation class|obj <relation> <target>
allows to set relations between objects, classes and mixins. This is a primitive command designed for the language developer, not for the user of the implemented object oriented language. The following relations are supported: mixin, instmixin, filter, instfilter, class, and superclass. The meaning of this relations is defined by the dispatcher, which is responsible for the linearizion of the commands.
The Tcl command ::oo::alias
::oo::alias class|obj methodName ?-objscope? ?-per-object? cmdName
registers a command (cmdName) under a certain name (methodName) to an object or class (1st argument) to make the command available as a method. The options -objscope makes instance variables of the object/class appear as local variables, therefore Tcl commands to which variable names are passed (e.g. set, append, lappend, ...) can access instance variables without additional effort.
namespace eval tcl-cool {}
::oo::class alloc ::tcl-cool::object
::oo::class alloc ::tcl-cool::class
After creation, the classes ::tcl-cool::class and ::tcl-cool::object are instances of ::oo::class. This is not what we want to have. tcl-cool::object should be the most general superclass of TclCOOL, and tcl-cool::class should be the most general superclass of TclCOOL. Without this redefinition ::tcl-cool::class and ::tcl-cool::object would not have methods (except alloc and dealloc), even if we provide methods for these base classes.
Since we are bootstrapping the language from a minimal command-set, we will use the setrelation command to define the basic relationships of the freshly defined classes.
First, we define that the superclasses of the newly defined class named ::tcl-cool::class) should be the general meta-class ::oo::class and as well ::tcl-cool::object. Therefore, ::tcl-cool::class will be a meta-class (its instances are classes) and it will inherit all properties of the most general TclCOOL class.
::oo::setrelation ::tcl::cool::class superclass {::oo::class ::tcl-cool::object}
The next two commands define that ::tcl-cool::object and ::tcl-cool::class are instances of ::tcl-cool::class. In other words, the class of e.g. ::tcl-cool::object is ::tcl-cool::class.
::oo::setrelation ::tcl-cool::object class ::tcl-cool::class ::oo::setrelation ::tcl-cool::class class ::tcl-cool::class
The basic OO-relations of the two basic classes are defined. In a next step of the bootstrapping we attach methods to these classes.
We define 3 methods for ::tcl-cool::class based on the method-set for classes:
method is a means to define the methods, which are provided to the instances of the class (instproc in XOTcl)
forward us a forwarder for instances of the object (instforward in XOTcl)
info is an introspection method for classes
::oo::alias ::tcl-cool::class method ::oo::methodset::class::instproc ::oo::alias ::tcl-cool::class forward ::oo::methodset::class::instforward ::oo::alias ::tcl-cool::class info ::oo::methodset::class::info
Next, we define 3 methods for object (actually ::tcl-cool::object) based on the method-set for objects:
variable is a means to import instance variables into the current scope (instvar in XOTcl)
forward is a method for delegating calls to different objects
info is an introspection method for objects
::oo::alias ::tcl-cool::object variable ::oo::methodset::object::instvar ::oo::alias ::tcl-cool::object forward ::oo::methodset::object::forward ::oo::alias ::tcl-cool::object info ::oo::methodset::object::info
The full definition of TclCOOL is available from [1]
This proposal defines only a small method-set (see above). However, it makes it straightforward to reuse the existing method-set (with maybe different names) without forcing an intermediate interpretation layer, or to load an additional method-set as extension. This additional method-set can be loaded dynamically via package require. The object system developer can provided the methods as Tcl commands in the extension's namespace. These commands can be attached to the objects and classes of the object system to be defined with the command ::oo::alias.
The command alias should not allow extensions to register methods on ::oo::object and ::oo::class. All application object systems should only be allowed to register their methods on the language specific superclasses.
The commands of the method-set are defined with the standard signature for Tcl commands but receive in their ClientData the object or class structure (like in today's XOTcl implementation). The handling for different client data (as for example for XOTcl's forwarders) is provided in an XOTcl style. C-extension writers can define non-leaf methods calling "next" from the C level.
static int MyMethod1( ClientData cdata, Tcl_Interp *interp,
int objc, Tcl_Obj *CONST objv[] ) {
int rc;
/* ... */
rc = Tcl_OONextObjCmd(cdata, interp, objc,objv);
/* ... */
return rc;
}
The primitive commands (like my, next, self, configure, ...) are provided by the OO namespace, and these can be provided by the extension writers by accessing the dispatcher structure and its stack.
All OO extensions can use the powerful dispatcher
If a certain extensions don't require filters, mixins, etc., they simply don't have to activate these.
The XOTcl dispatcher can be seen as a prototype implementation, but it should be replaced by a more efficient implementation with tighter core integration, provided the regression tests of the languages (e.g., XOTcl) continue to work.
The prototype implementation based on the current XOTcl 1.5.3 alpha release
is proven to work and sufficiently bug-free,
is free of memory leaks,
thread safe,
provides execution of the destroy callbacks when a thread or program exits,
provides uplevel transparency for interceptors,
is well suited for IDEs (an arbitrary class from a class tree can be reloaded and redefined without altering the relations between classes and/or instances)
All OO systems are treated equal
since we do not want to allow to register methods on ::oo::object or ::oo::class, there is no "preferred" object system,
every object system defines its own classes with its own names and own methods (although, it can reuse methods from all extensions with arbitrary names, as shown above)
there is no need to namespace export from "oo::*" (these are no end-user commands).
nobody is forced on any predefined semantics
no extensions are locked out
existing "high level" extensions (like XOTcl) and their applications (e.g. OpenACS) continue to work
since other OO language definitions are not part of the core, their development can continue,
other OO languages can easily benefit from the new core functionality
the dispatcher is based on a superset of the requirements of existing languages, so these should be able to use it.
extending the dispatcher requires a TIP.
This proposal is in the Tcl tradition of Tcl as a 2-level meta-language, since it provides a highly adjustable framework for object oriented languages.
Providing such a framework will attract people and put Tcl in front of the other OO scripting languages.
XOTcl 1.5.3alpha is the reference dispatcher (it should be rewritten for inclusion in the core, and serves here only as proof-of-concept) [2].
Example of the TclCOOL language (to be the _part_ of the framework) [3]
Example of a subset of ITcl based on this TIP (implemented with the framework, runs already part of the itcl regression tests: protection.test and basic.test, in the latter, only three error messages differ) [4]
Example of the XOTcl language (as implemented with the framework): See generic/predefined.xotcl in the XOTcl 1.5.3alpha reference implementation
This document has been placed in the public domain.
This is not necessarily the current version of this TIP.