No registered users in community xowiki
in last 10 minutes
in last 10 minutes
Re: [TCLCORE] Re: [Xotcl] TIP #257: Object Orientation for Tcl
From: Gustaf Neumann <neumann_at_wu-wien.ac.at>
Date: Thu, 29 Sep 2005 02:01:39 +0200
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
Date: Thu, 29 Sep 2005 02:01:39 +0200
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