Index: doc/object-class-appclass.png =================================================================== diff -u Binary files differ Index: doc/object-class.png =================================================================== diff -u Binary files differ Index: doc/tutorial2.html =================================================================== diff -u -r609d144413786df160f834692e7b571d0d5a92d8 -r9ee8d01537389a88bbbb560acb5f811d3e77422a --- doc/tutorial2.html (.../tutorial2.html) (revision 609d144413786df160f834692e7b571d0d5a92d8) +++ doc/tutorial2.html (.../tutorial2.html) (revision 9ee8d01537389a88bbbb560acb5f811d3e77422a) @@ -821,18 +821,17 @@ -

In XOTcl every object is associated with a class over the class -relationship. Classes are special objects with the purpose of -managing other objects. ``Managing'' means that a class controls the + +

In XOTcl every object is associated with its managing class by a relationship +called class. Classes are special objects with the purpose of +managing other objects. "Managing" means that a class controls the creation and destruction of its instances and that it contains a -repository of methods (``instprocs'') accessible for the instances. -Object-specific methods are called ``procs'', instance methods are -called ``instprocs''. +repository of methods accessible for the instances.

-

The instance methods common to all objects are defined in the root -class Object (predefined or user-defined). Since a class is a + +

Since a class is a special (managing) kind of object it is managed itself by a special -class called ``meta-class'' (which manages itself). Meta-Classes are +class called a "meta-class" (which manages itself). Meta-Classes are used to define classes and to provides methods for these. Most classes are defined by the predefined meta-class Class. One interesting aspect of meta-classes is that by providing a constructor @@ -845,46 +844,95 @@ reuse easily (more details about meta-classes are given in a later section).

+ +

The methods common to all objects in the XOTcl 2 object system are +defined in the root class Object (fully qualified name +::xotcl2::Object). All methods can be predefined (defined by +XOTcl) or user-defined. All objects of XOTcl 2 are either direct +instances of Object or instances of subclasses of +Object.

+ +

The most basic meta-class is Class (fully qualified name +::xotcl2::Class). All classes of XOTcl 2 are either direct +instances of Class or instances of subclasses of +Class. Since - as noted before - a class is a special kind of +object, Class is a subclass of Object. Therefore, +all methods available in all classes are the union of the methods of +Object and Class (see Figure 2a).

+ +

Figure 2a: +Basic Classes of the XOTcl2 object system +

+
+ +
+ +

+When we create an application class such as the class Stack +in the examples above, we create it as instance of the basic +meta-class ::xotcl2::Class. The application class will have +::xotcl2::Object as it superclass, unless we spefify this +differently. When we create an instance of the class Stack +(such as e.g. the stack s1) we create it by using the method +create provided by ::xotcl2::Class (an instance can +use the methods provided by its class). +

+ +

Figure 2b: +Application class Stack and instance of Stack together with the Basic Classes of the XOTcl2 object system +

+
+ +
+

XOTcl supports single and multiple inheritance. Classes are ordered by the relationship superclass in a directed acyclic graph. The root of the class hierarchy is the class Object. -A single object can be instantiated directly from this class. An -inherent problem of multiple inheritance is the problem of name +Note that it is possible to create as well objects from this most +general class; we have done this already above by creating an object +named stack.

+ +

A classical problem of multiple inheritance is the problem of name resolution, when for example two super-classes contain an instance method with the same name. XOTcl provides an intuitive and unambiguous approach for name resolution by defining the precedence order along a -linear ``next-path'' incorporating the class and mixin -hierarchies, which is modeled after CLOS. A method can invoke -explicitly the shadowed methods by the predefined command -next. When this command is executed a shadowed method is -``mixed into'' the execution of the current method. Method chaining -without explicit naming of the targeted method is very important for -languages supporting a dynamic class system, because one cannot always -predict which classes are currently participating in the inheritance -hierarchy at design time (often necessary in inheritance models, like -C++). -

-

An important feature of all XOTcl -objects is the read/write introspection. The reading introspection -abilities of XOTcl are packed compactly into the info -instance method which is available for objects and classes. All -obtained information can be changed at run-time dynamically with -immediate effect. Unlike languages with a static class concept, XOTcl -supports dynamic class/superclass relationships. At any time the class -graph may be changed entirely using the superclass method, or +linear "next-path" incorporating the class and mixin +hierarchies. A method can invoke explicitly the shadowed methods by +the predefined command next. When next is executed +a shadowed method is invoked. The execution of the shadowed methods is +called "method chaining". Method chaining without explicit naming of +the targeted method is very important for languages supporting a +dynamic class system, because one cannot always predict which classes +are currently participating in the inheritance hierarchy at design +time (often necessary in inheritance models, like C++).

+ + +

An important feature of all XOTcl objects +is the read/write introspection. The reading introspection abilities +of XOTcl are packed compactly into the info instance method +which is available for objects and classes. All obtained information +can be changed at run-time dynamically with immediate effect. Unlike +languages with a static class concept, XOTcl supports dynamic +class/superclass relationships. At any time the class graph may be +changed entirely using the superclass method, or an object may change its class through the class method. This feature can be used for an implementation of a life-cycle or other intrinsic changes of object properties (in contrast to extrinsic properties e.g. modeled through roles and implemented through per-object and per-class mixins [Neumann and Zdun 1999c] ) . These changes can be achieved without loosing the -object's identity, its inner state, and its per-object behavior (procs -and per-object mixins). +object's identity, its inner state, and its per-object behavior (methods +and mixins).

+ +xotcl2 changes until here, reminder is +missing;
+

  

-

Figure 2: +

Figure 2b: Object and Class System

@@ -910,8 +958,6 @@

 
Objects

-xotcl2 changes until here, reminder is -missing;
at least the first paragraph has to be rewritten; "2 commands" don't really hold

Initially XOTcl offers two new commands: Object and