Calling a user-specified (next-method) in STklos initialize methods

From: Christopher David Hundhausen <chundhau_at_cs.uoregon.edu>
Date: Thu, 13 Jul 1995 10:57:33 -0700 (PDT)

STklos hackers,

I have a quick question regarding the use of alternatives to (next-method)
in initialize. Consider the following example. Define three trivial
classes as follows:

(define-class <top-level> ((meta-slot)))

(define-class <first-level> ())

(define-class <second-level> ())

OK, now assume that the initialize method for <first-level> does some
initialization that is useful for instances of class <first-level>, but
that is _not_ useful for instances of class <second-level>:

(define-method initialize ((self <first-level>) initargs)

(next-method) ;call parent class's version of initialize

; Now do useful initialization stuff for <first-level> instances
.
.
.
)

Now we arrive at my question. Suppose that I want to define an initialize
method for class <second-level> that *bypasses* the intialize method for
<first-level>, instead calling the initialize function of <top-level>
directly. To bypass <first-level>'s initalize method, <second-level>'s
initialize method clearly _cannot_ call (next-method). What I'm looking
for, then, is a function of the form

  (parent-method <class-name>)

where <class-name> specifies the name of the parent class whose
initialize method is to be invoked. In other words, such a function
would allow programmers who knew what they were doing to _short circuit_
one or more parent class intialize methods. Does anyone have any advice?

Cheers,

Chris
*****************************************************************************
* Christopher D. Hundhausen chundhau_at_cs.uoregon.edu *
* Ph.D. Student, Department of Computer & Information Science *
* University of Oregon, Eugene, OR 97403-1202 *
* Phone: 503-346-0892 Fax: 503-346-5373 *
* WWW: http://www.cs.uoregon.edu/~chundhau *
*****************************************************************************
Received on Thu Jul 13 1995 - 20:09:57 CEST

This archive was generated by hypermail 2.3.0 : Mon Jul 21 2014 - 19:38:59 CEST