Thanks! That helps. And, yes, that was what I had in mind. I had similarly simple examples, but, when I said that I couldn't come up with a simple example, I meant that I couldn't come up with one that had a justifiable need, without getting reasonably complex.
I like both of the last two solutions, at least to some extent (the first one is, as you said, "rude"). I had proceeded down an approach similar to the second one, and found that it works. It just seems as if it is a general enough requirement that the language should have built in support for it (and I thought it might already be there and I couldn't find it). But, given the extensible nature of XOTcl (and Tcl, in general), I suppose I can add it to my environment and not worry about the rest of the world.
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. This still feels kind of wrong, but I can imagine there may be times when it works.
Finally, I did not appreciate all of the complexities that would be involved with eliminating polymorphism. (Of course, I don't really want to eliminate polymorphism; I just want to start the search higher up the tree.) I'm just glad there is someone in a position to appreciate, understand, and plan for these complexities.
Thanks again, Kurt Stoll
... 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