[Xotcl] Re: Abstract method f args called
Gustaf Neumann
Gustaf.Neumann at wu-wien.ac.at
Mon Feb 12 11:28:41 CET 2001
>>>>> "CL" == Catherine Letondal <letondal at pasteur.fr> writes:
CL> Hi,
CL> Say I have the following class hierarchy:
CL> Class C0
CL> C0 instproc f args {
CL> puts "(C0) I am [self] class [[self] info class] in method [self proc]"
CL> }
CL> Class C1 -superclass C0
CL> C1 abstract instproc f args
CL> Class C2 -superclass C1
CL> C2 instproc f args {
CL> puts "(C1) I am [self] class [[self] info class] in method [self proc]"
CL> next
CL> }
CL> So, the method f is:
CL> - defined at the top of the hierarchy
CL> - abstract in the middle of the hierarchy.
CL> - redefined at the bottom
CL> When I run:
CL> C2 c2
CL> c2 f
CL> I get:
CL> (C1) I am ::c2 class ::C2 in method f
CL> Abstract method f args called
CL> and I cannot reach the top method?
CL> Is this on purpose?
Hmm, actually kind of. It was on purpose that "abstract" should be
used at the highest possible point in the class hierarchy, where the
specified method makes sense (similar to an abstract class say in
C++).
For your example, i would really question whether this use of
abstract is a good design.
However, if you insist on this kind of class hierarchy, you might
consider to redefine "abstract. Our implementation of abstract is very
simple
=========================================================================
Object instproc abstract {methtype methname arglist} {
if {$methtype != "proc" && $methtype != "instproc"} {
error "invalid method type '$methtype', must be either 'proc' or 'instproc'."
}
[self] $methtype $methname $arglist \
[list error "Abstract method $methname $arglist called"]
}
=========================================================================
and can be redefined by any user. so "abstract" is not an integral
language construct but more like a library function in XOTcl.
best regards
-gustaf
More information about the Xotcl
mailing list