This is a page for information, tips and hits about the XOTcl object oriented extension. Useful code tidbits: * [Cacheable class]. This 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. ---- Partly taken from the XOTcl homepage [http://www.xotcl.org/]: 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 functionalities 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. * 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. ---- [Zoran Vasiljevic] describes: "... 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 incrTcl since it ihas more of the dynamic nature of Tcl than incrTcl does. The incrTcl is more appealing to c++/java programmers. Xotcl should be more appealing to Tcl programmers, IMHO." ---- See also [XotclIDE]. ---- See also [XOTcl Documentation Tool]. ---- An example posted by Gustav Neumann in [the comp.lang.tcl newsgroup]: XOTcl supports "open class definitions", object specific behavior and mixin classes (among other things) to achieve dynamic behavior extensions. The so-called per-object mixins are actually an implementation of the decorator pattern that Bob mentions. The following example is modelled to express the intentions from the examples earlier in this thread. hope, you find it interesting best regards -gustaf ---- # Here is the original example: a method from a derived class # extends the behavior of the baseclass; the primitive "next" # calls other same-named methods. In the example below, the # baseclass method "speak" is called at the beginning of the # derived-class method. The primitive "next" can be placed at # arbitrary places, or it can be omitted when the baseclass method # should not be called. Class BaseClass BaseClass instproc speak {} { puts "Hello from BC." } Class DerivedClass -superclass BaseClass DerivedClass instproc speak {} { next puts "Hello from DC." } DerivedClass create o1 o1 speak # The output is: # Hello from BC. # Hello from DC. # There are many ways to extend the behavior XOTcl classes # at runtime. The easiest thing is to add methods dynamically # to classes. E.g. we can extend the BaseClass with the method # unknown, which is called whenever an unknown method is called. BaseClass instproc unknown {m args} { puts "What? $m? I don't understand." } o1 sing # The output is: # What? sing? I don't understand. # Often, you do not want to extend the class, but to # modifiy the behavior of a single object. In XOTcl, an object # can have individual methods: o1 proc sing {} { puts "Ok, here it goes: Lala Lala!" } o1 sing # The output is: # Ok, here it goes: Lala Lala! # In many situations, it is desired to add/remove a set # of methods dynamically to objects or classes. The mechanisms # above allow this, but they are rather cumbersome and do # support a systematic behavior engineering. One can add # so-called "mixin classes" to objects and/or classes. For # example, we can define a class M for a more verbose methds: Class M M instproc sing {} { puts -nonewline "[self] sings: " next } M instproc unknown args { puts -nonewline "[self] is confused: " next } # The behavior of M can be mixed into the beavior of o1 through # per object mixins ... o1 mixin M # ... and we call the methods again: o1 sing o1 read # The output is: # ::o1 sings: Ok, here it goes: Lala Lala! # ::o1 is confused: What? read? I don't understand. # We can remove the new behavior easily by unregistering the # mixin class .... o1 mixin "" # ... and we call the methods again: o1 sing o1 read # The output is: # Ok, here it goes: Lala Lala! # What? read? I don't understand. # Mixin classes can be used to extend the behavior of classes # as well. BaseClass instmixin M o1 sing o1 read DerivedClass create o2 o2 read # The output is: # ::o1 sings: Ok, here it goes: Lala Lala! # ::o1 is confused: What? read? I don't understand. # ::o2 is confused: What? read? I don't understand. ---- * [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)] ---- Gustaf Nuemann writes to the XOTcl mailing list [http://alice.wu-wien.ac.at/pipermail/xotcl/2003-July/000426.html] on 20Jul03: ...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 conceptionally quite hard for this setup. Object-oriented (in this distinction) means that the primary elements are objects, which keep all instance variables. classes my 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 objects 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. ---- [Category Object Orientation] | [Category Package]