No registered users in community xowiki
in last 10 minutes
in last 10 minutes
Re: [Xotcl] XOTcl method call precedence order
From: Gustaf Neumann <neumann_at_wu-wien.ac.at>
Date: Fri, 06 Oct 2006 11:48:49 +0200
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
Date: Fri, 06 Oct 2006 11:48:49 +0200
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