Neil Madden schrieb:

Is this description correct?

Mostly yes, let me try to explain:

- the precedence order is defined by the order, classes are priorized or shadow each other. Abbreviations: POM: per-object mixin, PCM: per-class mixin, C: Classes The 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) * 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 precodintion 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. Also here, it would make sense to develop "unknown" to a more general exception handler.

The only two mechanisms that I don't know where to put are assertions

and forwarders. Are these

implemented using e.g. mixins? Or are they a special-purpose

mechanism? If so, where do they come in the > order?

Forwarders are c-implemented methods. They are pure conveniance and could be implemented my 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.

-gustaf neumann