"CL" == Catherine Letondal letondal@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