[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