[Xotcl] Non-polymorphic methods (long post)
Kurt Stoll
stoll at mac.com
Sun Feb 26 17:39:54 CET 2006
(Sorry for the long post)
Well, I've perused the archives and can't find anything on this
topic. Nor can I find it in the tutorial or reference guide. So, I
must conclude that I am missing something. Either this is obvious,
and everyone has already figured this out. Or, there is no real need
for this type of a construct and I'm thinking about this incorrectly.
Many OO languages provide a means to make some methods be polymorphic
and some not. For example, C++ uses the virtual keyword to make a
function polymorphic; otherwise it's not. XOTcl on the other hand
appears to only support polymorphic methods. A call to a method from
a given level of the hierarchy starts from the class of the calling
object and works its way up (assuming next is used).
For example, a class Base provides an interface, then Sub1 and Sub2
(both subclasses of Base) provide a thin veneer on that interface.
The methods have the same name. And, in some cases, they rely on
Base to provide some of the functionality. But, Base provides its
own functionality by composing some of its own methods into more
complex methods. Now, when a method from Sub1 is called, it calls
that method in Base, and Base then calls another method within Base -
except that when it makes this call, it gets the version from Sub1.
In some cases, this may be the correct approach. But, there are
certainly cases where this is not desired.
We could try pushing some of the implementation from Base into Sub1,
but Sub2 wants similar functionality. This would mean duplicating code.
Another approach might be delegation, instead of inheritance. This
would work, but, all three classes (Base, Sub1, and Sub2) have
instances that share a common interface. Now, to add a new method to
that interface requires changing two different class hierarchies.
Again, this would work, but it just doesn't feel right.
I realize that this is a fairly abstract presentation of the issue.
I have attempted to come up with a simple example - for example,
geometric figures, with the base class rooting the centroid at the
origin to provide easy rotations. But, even here, this gets
complicated. and I'm afraid that the discussion will veer off to
trying to solve some particular quirk of the example. But, I have
run into this issue several times, and have found it frustrating.
The only solution that I have found is to provide both an "internal"
implementation and a public implementation of some methods (for
example, prefix the internal method name with an underscore). Then,
the implementation can decide whether it is wants to use the
polymorphic method or the non-polymorphic version. But, this doesn't
really solve the problem - I still have to be careful not to override
the internal version (because, I don't really have a non-polymorphic
method - I just have some conventions to avoid the polymorphism).
This could get truly complicated with a large class hierarchy, but
none of my constructs have reached the point (yet).
Actually, I can imagine a second potential solution, although I have
not tried it. I think it would work, but would be very ugly.
Nevertheless, I bring it up because I believe it might form the basis
of what I think would be an elegant solution to this problem. I
could temporarily change the class of the object to reflect where I
want the method search to begin from. Then, change it back when the
method returns. Artificially changing the class of an object makes
me cringe - I don't really like this approach.
But, it seems to me that if XOTcl can provide a way to force the
method search to begin at a particular class, this would fix the
problem. Maybe something like: [self as class] <method> <args>. In
fact, I think I can implement this as an Object method - simply copy
the class, change it, make the call, destroy the copy, and return the
result. I think this would work, and may try it. But, I still feel
like I must be missing something.
Any thoughts would be appreciated.
Thanks,
Kurt Stoll
More information about the Xotcl
mailing list