Dear XOTcl community,

i am sure, some of you are following with interest the discussions about TIP #257 (adding OO to the core), where the proponents have developed an (incompatible) subset of XOTcl, that gives me the impression, that it will be very hard to build on it. There is a new implementation built from scratch, the implementor repeats, that he is not understanding certain functionalities from XOTcl (e.g. instmixins), is fixing hard bugs (forgot e.g. to loop check on filters), is not handling thread/interpreter exits, etc. It will take a while to debug the code, many other problems will (naturally) show up with that code. The code does not seem to be build for extensibility. Functionalities, that were dropped from XOTcl that depend on dispatcher or callstack properties are very hard to extend, especially, when there are no hooks. The implementor has no ear for xotcl requests and repeats that he has no time. Maybe i see the situation to negative, but i don't think currently, the TIP is going into a direction doing a good thing for the Tcl community (or XOTcl in particular).

Here is a slightly different proposal. Let me know, what you think about it. I have this proposal already implemented (see below, 1.5.3alpha) and i am wondering - no matter how the TIP develops - whether we should go this direction with XOTcl. Allthough the first set of regression tests work already with an accordingly bootstrapped XOTcl, the introspection tests don't work (since there are now two top-level classes above ::xotcl::Object and ::xotcl::Class. Btw, the implementation took me less time than writing this proposal, and fits very nice with the new slot model (one can define a default superclass with the standard slot mechanism for e.g. "::xotcl::Class Dog", where te superclass of Dog should be ::xotcl::Object" and not necessarily the topmost superclass).

The change will be visible in XOTcl programs, since there will be two new top-level classes. If you care and you have objections against adding these classes, please let me know. In case there is a strong objection, i will reconsider this change.

-gustaf neumann

The proposal:

Rather than proposing any kind of OO language, i would suggest to add a framework to the core, that every extension (including XOTcl) can use. This framework is not useful as an OO language on its own, but 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.

This approach (and implementation) is much closer aligned with the original intention suited for multiple object systems. This proposal provides a flexibility much higher than in other popular scripting languages and lets object systems designer continue to improve their work.

My proposal is to add a framework consisting of an flexible enough object interpreter (dispatcher) able to run the most powerful current object extensions. This dispatcher is accompanied by a "minimal object system" 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 e.g. setting up the object/class relations and registering methods). The remainder of the object system (like XOTcl) can be loaded as an extension (being not part of the core), but providing the method set.

The Minimal Object System

The minimal object system consists of a base class (::oo::object) and a meta-class (::oo::class, subclass of ::oo::object).

superclass instance-of ::oo::object class ::oo::object ::oo::class ::oo::class meta-class ::oo::object ::oo::class

The meta-class ::oo::class has a single method named "alloc" (name is 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.

Example for XOTcl:

Create base and meta class:

oo::class alloc ::xotcl::Object oo::class alloc ::xotcl::Class

Define relation to the minimal object system:

::xotcl::setrelation ::xotcl::Class superclass {::oo::class ::xotcl::Object} ::xotcl::setrelation ::xotcl::Object class ::xotcl::Class ::xotcl::setrelation ::xotcl::Class class ::xotcl::Class

The superclasses of ::xotcl::Class are defined to be ::oo::class and ::xotcl::Object. ::xotcl::Object and ::xotcl::Class are defined as instances of ::xotcl::class. The command setrelation supports the following relations: "mixin", "instmixin", "filter", "instfilter", "class", and "superclass" (alternatively, a reduced set "mixin", "filter", "class", and "superclass", when a flag "per-object" can be specified). The meaning of this relations is defined by the dispatcher, which is responsible for the linearizion of the commands.

Methods from extensions:

This proposal does not define methods (maybe except alloc), but instead an extension mechanism for defining methods. An implementor of an OO-language can provide methods. These methods 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. This is achieved by the command alias:

::oo::alias <class|object> methodName cmdName

The following three commands register the method "instvar" and "proc" for ::xotcl::Object (available for all objects in XOTcl) and "instproc" for ::xotcl::Class

::xotcl::alias ::xotcl::Object instvar ::xotcl::cmd::instvar ::xotcl::alias ::xotcl::Object proc ::xotcl::cmd::proc ::xotcl::alias ::xotcl::Class instproc ::xotcl::cmd::instproc

The name of the method (3rd argument) can differ from the name of the command (4th argument). Therefore, also the "alloc" method mentioned above can be registered the same way under arbitrary names. The same command can be registered under several names for different objects or classes.

The command alias should not allow to register methods on ::oo::object and ::oo::class. All end user object systems should only be allowed to subclass (e.g. oo::object or ::xotcl::Object) and to register the methods on their objects and classes.

The registered methods are defined with the standard signature for TclCommands but receive in ClientData the object or class structure (like in today 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.

Example: static int MyMethod1( ClientData cdata, Tcl_Interp *interp, int objc, Tcl_Obj *CONST objv[] ) { int rc; /* ... */ rc = XOTclNextObjCmd(cdata, interp, objc,objv); /* ... */ return rc; }

The primitive commands (like my, next, self, configure, ...) can be provided by the OO namespace (if there is sufficient agreement), or can be provided by the extension writers (provided they have access to obtain the needed information).

Advantages:

- 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 can 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 * 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 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 continue to work * the XOTcl language definition is not part of the core, its development can continue * the XOTcl requirements are a superset of the requirements of other languages. * XOTcl can be executed with essentially the same speed as current versions.

- 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, at least in terms of flexibility.

Sample Implementation:

The actual snapshot of XOTcl is based on this framework using ::oo::object and ::oo::class as base object system. It contains a preprocessor variable OO, that turns on the sub-classing of the base object system (per default). The XOTcl C-Code does defines only oo::object and oo::class, the XOTcl base objects are created already by the scripting code.

Note, that this is a preview version of XOTcl and not suited for running critical applications on it. It is passing the the first sets of the regression tests but fails on the introspection regression tests (it is not expecting to see e.g. ::oo::object as base class). It would be possible to hide the base object system from the introspection, but i am not sure this is a good idea. I am waiting for some feedback from the community before either finishing the regression test or removing the sub-classing of ::oo::object again.

Here is the snapshot code: http://media.wu-wien.ac.at/download/xotcl-1.5.3-alpha.tar.gz

Below is the basic script level initialization for XOTcl, where the classes ::xotcl::Object and ::xotcl::Class and their methods are defined.

best regards -gustaf neumann

=================================================== # $Id: predefined.xotcl,v 1.12 2006/10/04 20:40:23 neumann Exp $ if {[info command oo::object] ne ""} { ::xotcl::alias ::oo::class alloc ::xotcl::cmd::Class::alloc oo::class alloc ::xotcl::Object oo::class alloc ::xotcl::Class ::xotcl::setrelation ::xotcl::Class superclass {::oo::class ::xotcl::Object} ::xotcl::setrelation ::xotcl::Object class ::xotcl::Class ::xotcl::setrelation ::xotcl::Class class ::xotcl::Class }

# provide the standard command set for ::xotcl::Object foreach cmd [info command ::xotcl::cmd::Object::*] { ::xotcl::alias ::xotcl::Object [namespace tail $cmd] $cmd } # provide some Tcl-commands as methods for ::xotcl::Object foreach cmd {array append eval incr lappend trace subst unset} { ::xotcl::alias ::xotcl::Object $cmd -objscope ::$cmd } # provide the standard command set for ::xotcl::Class foreach cmd [info command ::xotcl::cmd::Class::*] { ::xotcl::alias ::xotcl::Class [namespace tail $cmd] $cmd } # "init" must exist on Object. per default it is empty. ::xotcl::Object instproc init args {}