No registered users in community xowiki
in last 10 minutes
in last 10 minutes
Re: [Xotcl] Non-polymorphic methods (long post)
From: Gustaf Neumann <neumann_at_wu-wien.ac.at>
Date: Wed, 01 Mar 2006 13:24:33 +0100
... before i forget, a small comment to your comment:
Kurt Stoll schrieb:
> The last solution is one that I had not considered. I find it intriguing
> and may use it as well. My first objection was that a class proc does not
> normally have access to instance variables. But, this can be solved by
> passing in the object itself.
The approach using procs as in
Base instproc foo {} {
[self class] bar 1 2
}
Base proc bar {x y} {
puts "[self] [self proc] $x $y"
}
is based on delegation (delegation to the class object), which is a pattern
frequently very handy. One can pass the object implizitely, or one can relay
on callstack information to access the objects state:
Base proc bar {x y} {
puts "[self] [self proc] $x $y"
[self callingobject] instvar x y z
}
This behaves well with interceptors as well (i am proposing this as
an option, not a general solution)
> Of course, I don't really want to eliminate
> polymorphism; I just want to start the search higher up the tree.
"starting higher in the tree" can lead to strange behavior, when
mixins are involved. temporary reclassing does not have this problem.
-gustaf
Date: Wed, 01 Mar 2006 13:24:33 +0100
... before i forget, a small comment to your comment:
Kurt Stoll schrieb:
> The last solution is one that I had not considered. I find it intriguing
> and may use it as well. My first objection was that a class proc does not
> normally have access to instance variables. But, this can be solved by
> passing in the object itself.
The approach using procs as in
Base instproc foo {} {
[self class] bar 1 2
}
Base proc bar {x y} {
puts "[self] [self proc] $x $y"
}
is based on delegation (delegation to the class object), which is a pattern
frequently very handy. One can pass the object implizitely, or one can relay
on callstack information to access the objects state:
Base proc bar {x y} {
puts "[self] [self proc] $x $y"
[self callingobject] instvar x y z
}
This behaves well with interceptors as well (i am proposing this as
an option, not a general solution)
> Of course, I don't really want to eliminate
> polymorphism; I just want to start the search higher up the tree.
"starting higher in the tree" can lead to strange behavior, when
mixins are involved. temporary reclassing does not have this problem.
-gustaf