Donal K. Fellows schrieb:
There are two 'move' methods/instprocs. One is in the XOTcl base Object class, and one is in C.
ok, i though this was already omitted :)
Perhaps I should explain more about what I was asking about. :-)
What I did was I constructed the situation according to the attached diagram (sorry to everyone for doing an attachment, but I refuse to do ASCII art for this!) and what I wanted to know was, given that we've got a per-object mixin, would the foo inherited from A by B be mixed in at higher precedence than the foo gained by D directly from C. If that's
the case, would the move inherited from Object through the mixin side override the move gained directly from C? As far as I can tell as someone who has not thought about this in detail, that's the only way to do this sort of thing consistently. But it also means that mixins will stamp all over any attempt to redefine behaviour for a particular application domain.
Look at the precedence order:
% D info precedence ::B ::A ::C ::xotcl::Object
therefore C->move before ::xotcl::Object->move
it would be no good idea to define this as you mentioned above ::B ::A ::xotcl::Object ::C
since e.g. on an "D destroy" the object would be deallocated though ::xotcl::Object and a destructor in C would never be called. Since every class is a subclass of ::xotcl::Object, mixin would not work in any useful way, at least when class hierarchies are mixed in. Mixing in single classes would be rather limited.
we call the mapping from the class structure to the order classes are searched "linearization". It takes care that the more general classes are not preceding subclasses.
If I'm wrong and I've overlooked something, what is it? It's certainly not clear to me. (Mind you, it's midnight as I write this so the old braincells might not be producing maximum clarity anyway. ;-) )
I hope this all explains why I was asking what appears to be on the surface a trivial question, and the answer should clear up the details of what I don't know about XOTcl inheritance rules from reading the documentation.
The follwing paragraph in the section "Precedence Order" in the tutorial is supposed to describe linearization. Sorry, if this is not clear enough:
Filters as well as classes (mixins and ordinary classes) are linearized. That means, each filter and each class can be only once on a precedence order list. If a filter or class can be reached more than once, the last occurrence is used.
best regards -gustaf neumann