[Xotcl] XOTcl method call precedence order

[Gustaf Neumann]

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