the time, you may want to specify some additional behavior to the original. This presents a problem: how to call your superclass' method from within the overriding method D)will give rise to an infinite loop Thus, instead of asking ourself, we ask our superclass-part. Note that we do this with the INSTALL method of a thing, where we explicitly ask the superpart to also install, as well as doing some specific actions. This is the only situation in which you should be asking your superclass-part! Classes for a simulated worl When you read the code in objtypes. scm, you will see definitions of several different classes of objects that define a host of interesting behaviors and capabilities using the OOP style discussed in the previous section. Here we give a brief"tour" of some of the important classes in our simulated world Container Class Once we have things, it is easy to imagine that we might want containers for things. We can define a utility container class as shown below: (define (container self) (let ((root-part (root-object self)) (things ()) (make-handler container (make-methods I THINGS (lambda ( things) HAVE-THING? (lambda (thing) (not (null? (memg thing things)))) ADD-THING (lambda (thing) (if (not (ask self HAvE-THING? thing) (set! things (cons thing things))) DEL-THING (lambda (thing) (set! things (delg thing things)) DONE)) root-part))) Note that a container does not inherit from named-object, so it does not support messages such as NAME or INSTALL Containers are not meant to be stand-alone objects to create dure); rather, they only meant to be used internally by other objects to gain the capability of adding things, deleting things, and checking if one has something Place classthe time, you may want to specify some additional behavior to the original. This presents a problem: how to call your superclass' method from within the overriding method. Following the usual pattern of (ask self 'METHOD) will give rise to an infinite loop! Thus, instead of asking ourself, we ask our superclass-part. Note that we do this with the INSTALL method of a thing, where we explicitly ask the superpart to also install, as well as doing some specific actions. This is the only situation in which you should be asking your superclass-part! Classes for a Simulated World When you read the code in objtypes.scm, you will see definitions of several different classes of objects that define a host of interesting behaviors and capabilities using the OOP style discussed in the previous section. Here we give a brief "tour" of some of the important classes in our simulated world. Container Class Once we have things, it is easy to imagine that we might want containers for things. We can define a utility container class as shown below: (define (container self) (let ((root-part (root-object self)) (things '())) (make-handler 'container (make-methods 'THINGS (lambda () things) 'HAVE-THING? (lambda (thing) (not (null? (memq thing things)))) 'ADD-THING (lambda (thing) (if (not (ask self 'HAVE-THING? thing)) (set! things (cons thing things))) 'DONE) 'DEL-THING (lambda (thing) (set! things (delq thing things)) 'DONE)) root-part))) Note that a container does not inherit from named-object, so it does not support messages such as NAME or INSTALL. Containers are not meant to be stand-alone objects (there's no create-container procedure); rather, they are only meant to be used internally by other objects to gain the capability of adding things, deleting things, and checking if one has something. Place class