XOTcl

XOTcl is an object system, currently at version 1.6.7

Attributes edit

website: http://www.xotcl.org
website: http://media.wu-wien.ac.at/
contact: mailto:[email protected] (Uwe Zdun)

Obtaining edit

XOTcl is included in ActiveTcl and WinTclTk.

SYStems: Does anyone know where I can get recent Debian packages for XOTcl? Sarge doesn't have any XOTcl packages at all.

vkvalli: XOTcl on debian

Response edit

Zoran Vasiljevic says, "... it runs leak free, does not crash, obeys to what's written in the manual, is thread-safe, can be used under AOLserver or under Tcl threading extension w/o problems, is loaded with features., checked with Purify..."

We have written 100K lines in Xotcl and I find it very valuable. I like it more than [incr Tcl]] since it ihas more of the dynamic nature of Tcl than [incr Tcl] does. The [incr Tcl] is more appealing to C++/Java programmers. Xotcl should be more appealing to Tcl programmers, IMHO."

Documentation edit

official documentation

Description edit

Extended OTcl - exotickle - is a value added replacement of the MIT OTcl object extension. In addition to all the OTcl bonuses like meta-classes, multiple inheritance and read/write introspection, XOTcl adds Per-Objects Mix-ins, Filters, Nested Classes, Dynamic Object aggregations, metadata and assertions. All of these features together allow easy construction of high-level patterns and structures and simultaneously follow the Tao of Tcl.

XOTcl combines the ideas of scripting and object-orientation in a way that preserves the benefits of both of them. It is equipped with several new language functions that help building and managing complex systems. It supports the following features:

Dynamic Object Aggregations, to provide dynamic aggregations through nested namespaces (objects).
Nested Classes, to reduce the interference of independently developed program structures.
Assertions, to reduce the interface and the reliability problems caused by dynamic typing and, therefore, to ease the combination of many components.
Per-object mixins, as a means to improve flexibility of mixin methods by giving an object access to several different supplemental classes, which may be changed dynamically.
Per-class mixins, as a means to improve flexibility of mixin methods to a class, all instances of the class have access to the mixed in methods like for multiple inheritance, but without the need of intersection classes.
Per-class and per-object filters, as a means of abstractions over method invocations to implement large program structures, like design patterns.
Dynamic Component Loading, XOTcl integrates the Tcl package loading with architectural support for integration with object oriented constructs. Moreover, it provides tracking/tracing of component loading.
Dynamic read/write introspection and extensibility.
Meta-classes.

Gustaf Neumann, XOTcl mailing list

, 2003-07-20:

: ...let me re-iterate the basic "philosophical" point of view. Languages like xotcl are object oriented, while languages like Java (and most of UML) is class-oriented.
: Class-oriented means: look at the class and you know exactly how all of the instances look alike. The class is the first and primary language construct; the class is well the place where you specify the instance variables (there are no instance variables except those specified in the class). The only kind of individualism left in the objects is to let them differ by their state (the values of their instance variables). Changing classes (class migration) is conceptually quite hard for this setup.
: Object oriented (in this distinction) means that the primary elements are objects which keep all instance variables. classes may be used to specify the behavior of objects, they are container for methods and they control the life-cycle of objects. Objects are like the facts, and classes are like rules, that determine the behavior of the objects. Since the connection between objects and classes is rather loose, it is sufficient to define their relation through an association. Therefore it is quite easy to change the relation between objects and classes (and between classes and classes) dynamically. Objects have arbitrary individualism, they may have variables never used in any class, they may have private procs etc.
: From the expressiveness, object oriented languages can - in principle - be restricted to behave like class-oriented languages, but the other way around is much harder.

XOTcl is thread safe (see Thread-safe Tcl Extensions) and one of the fastest OO Tcl Extensions (see Tcl OO Bench).

GN: Preexisting aolserver applications can be extended with XOTcl; new ones can be written based on XOTcl. The OpenACS core group decided to use XOTcl as a requirement starting with 5.3. OpenACS support for XOTcl and several OpenACS packages can be obtained from the OpenACS cvs HEAD version.

Invocation order of XOTcl edit

DKF: The XOTcl Method Traversal Order is fairly complex and not especially well documented, and so merited its own page.

GN: Here is a summary of the invocation order of XOTcl:

the precedence order defines the order, in which classes are prioritized or shadow each other.
Abbreviations: POM: per-object mixin, PCM: per-class mixin, C: Classes
The precedence order is: POM, PCM, C
All of these are class hierarchies, where the contained classes are linearized; when a class is mixed into a precedence order, where it is already present, it has no effect.
the method resolution order overlays the precedence order. it includes
- filters (firstly per-object filters, then per-class filters), dispatched "on top" (i.e. before the methods of the precedence order): filters can change the results of methods.
- object specific methods (dispatched between PCM and C)
- assertions (per default, turned off):
  - assertions are turned on/off on a per-object basis
  - assertions are lists of Tcl expressions
  - we distinguish between pre- and post-conditions and invariants
  - pre- and post-conditions are defined per-method (more precisely instproc and proc)
  - a precondition is evaluated before every method dispatch (method-specific)
  - a postcondition is evaluated before after method dispatch (method-specific)
  - an invariant is evaluated before and after every method dispatch for the object
  - these three types can be selectively activated/deactivated

Assertions are similar to the :before, :after, :around in CLOS, but all three types (as they are defined in current XOTcl) do not change the result of a method. Assertions, as we have these today, are specialized, but could be generalized to something more CLOS-like.

Finally, "unknown" is an exception handler, invoked in case the method to be dispatched is not defined by the classes in the precedence order or by the object. This means, a mixin containing a certain method can prevent that unknown is called.

Forwarders are c-implemented methods. They are pure convenience and could be implemented by the user as methods as well. If a class providing an forwarder to its instances is mixed in, the forwarders are mixed in as well.

Pre- and post-conditions can be implemented roughly with mixins, but they cannot measure the immediate effect of a single method call (mixins would implement the pre- and postconditions of an invocation of a next-chain). All tree types can however be implemented by filters (which can alter results). It would be quite slow, and give no nice error traces. It will be some work, but it should be possible. It is hard to say, what on this level cannot done with filters.

Useful code tidbits edit

XOTcl Introductory Example: shows how XOTcl diffes from, e.g., itcl by providing "open class definitions", object-specific behavior and mixin classes (among other things) to achieve a more dynamic behaviour.

XOTcl Objects as Tcl Commands with subcommands:

chan command in XOTcl: Cacheable class: shows how filters can be used to build a transparent cache for specified methods. Because of the nature of XOTcl this can be dynamically mixed into objects and their class hierarchies and later removed when not necessary.

Safe XOTcl object creation: There are some 'gotchas' in object instantiation with XOTcl. Here is code snippet to make things cosy and safe.

Category XOTcl Code: more code examples

Comparison with other Tcl OO Extensions edit

Itcl in XOTcl. This is an example how to implement a ITcl-like language in XOTcl.
Xoins. This is a XOTcl class that emulates a snit-like object system.
Snit like Delegation in XOTcl: an example how to implement delegation like in snit in XOTcl.
Tcl OO Bench, A simple comparison of Tcl object extensions

Less closely related edit

Thingy OO with classes: adds class functionality to Thingy: a one-liner OO system in a style similar to XOTcl.
another minimal Tcl object system (XOTcl like syntax)

NEM 2004-04-18: I guess a question which comes up with any object system eventually is "has anyone written a mega-widget framework with this yet?" It seems to me that XOTcl is a pretty powerful object system, and so could probably form the basis of a very nice widget framework. Has anyone done any experiments in this direction? How would you go about it? Create a new meta-class type construct (Widget or something like that)? Doing something like this as an exercise might be a useful way to show off some of the more powerful features of XOTcl, and how they can be used to good effect.

Artur Trzewik 2004-04-19: There are pretty many [GUI ]Stuff in XOTclIDE in component IDEBaseGUI. It is not complete GUI Framework but some special classes that offer OO way to use Tk. For example Menu-Framework that can control automatic menu enablement and same time pop-up menus. Also

Standards Dialogs. Entry Dialog, List Chooser, ...
Framework for modeless Dialogs
Editor Widgets (with save callback, file open and save)
List dialog class that can be used by inheritance to program own logic (the way it was used in XOTclIDE)

Indeed XOTcl works pretty well with other widget frameworks. I have used Tix and BWidget without problems. Even ITk is possible (but not tested be myself).

WHD 2004-04-23: Artur, I think you're describing a collection of widget-like objects written in XOTcl; what Neil was asking about was a straightforward means of creating new widgets in XOTcl, rather like snit::widgets which work like and interoperate with Tk widgets. So let me ask the question a different way: Using XOTcl, is it possible to create an object that looks and acts like a Tk widget?

Artur Trzewik 2004-04-23: Yes, it is possible to create Tk-like widgets with XOTcl (the same do Tix or ITk). But you not really want it. Because Tk is not realy OO (it has some OO characteristic because options by some widget has the same name).

You can not build a child class of the button or text Tk widgets, but it is a base technique for OO widget set. Therefore really OO widget set would wrap Tk widget and not build some new Tk-like widget.

XOTcl widget set should be more like WinForms from .NET, Qt, or Java Swing. For example with XOTcl is possible to use more program techniques than Tk offers. One problem of adapting Tk to OO is lack of events (Publisher-Subscriber Model) that is useful for implementing Model View Controller Pattern. In this case you must wrap Tk in XOTcl-Classes and program it yourself. Other tasks were: Validators, Buffering, Building from XML.

Some techniques of using Tk in XOTcl were also discussed in XOTcl mailings; see the XOTcl mailing list

(I do not remember the month, June 2004 probably) [2]

The question is what to you want achieve with XOTcl widget set.

new Tk widgets (XOTcl is hidden from user)
Tk megawidgets (XOTcl is hidden from user)
OO Widgetset with OO Techniques (Model View Controller). Not Tk specific

For me Tk is good base widget set. But in OO-Application you will rather wrap them in your classes and adapt them to your OO-use specific for your application. The advantage of XOTcl is not the possibility to build new Tk-Widgets but rather use them in OO-manner.

Sarnold: What about snit emulation with Xoins? It already supports snit::widget emulation (non-surprisingly named xoins::widget), and the current release (O.5p1) handles also widgetadaptors. It is, being build on the top of XOTcl, faster than snit, especially at instantiation.

Strick 2004-01-11: Does anyone have hints on using XOTcl in a safe interpreter? It doesn't have a Xotcl_SafeInit(), so you can't load it. Aliasing it from a full interpreter is a bad idea: "Object eval" would give you access to the full interpreter. It looks like I'll have to do surgery on the sources? The paper, Semantic lookup in service-oriented architectures

, U. Zdun, 2004, makes me think it's been done before.

SRIV: In response to Artur's comment "Yes it is possible to create Tk-like widgets with XOTcl, but you not really want it." ... I want it. For Tk to gain momentum, it needs to be extensible. Using any other paradigm because you feel it is superior is just unacceptable.

RLH: "For Tk to gain momentum" - exactly what do you think that means? Tk has been around a long time and while other "dynamic" languages use Tk the more popular ones are moving to other toolkits. Python has Tkinter but wxPython is preferred (a book is in the works as well), Ruby has Tk but most use either Fox Toolkit or [wx] again. Perl uses Tk but I see wxPerl coming up now and when it gets a bit more mature and a bit more exposure I see that becoming the toolkit there as well. Now it is possible that Tile will be able to move some back to using Tk but I don't see a mass migration back to Tk because of it.

SRIV You answered your own question.

RLH I rambled yes.

Category Object Orientation

Category Package