A class's slots are a combination of those explicitly defined in its slot description list and the slots it inherits from its superclass. In Quintus Objects, a class inherits all the slots of its superclass. It follows that a class inherits all the slots of all its ancestors.

The programmer's control over inheritance of slots is limited. It is not possible to rename an inherited slot, nor is it possible to change its type, unless it is a class slot. It is possible to change a slot's initial value. And, it is possible to effectively change a slot's visibility.

To change the initial value or the type (when allowed) of a slot, include a new SlotDef in the list of slot descriptions for the class, with the same slot name and a new type or initial value. The type of a class slot can only be changed to a subclass of the type of the superclass's slot. The new initial value must still be a constant of the appropriate type.

The named_point class, defined earlier, could have better been defined from the point class, which began as follows:

     :- class point =
             [public x:float=0,
              public y:float=0].

The definition of the named_point class would then begin with

     :- class named_point =
             [public name:atom,
              public x:float=1.0] + point.

This named_point class has public slots named name, x and y, with the same types and initial values as the earlier named_point definition, which did not use inheritance. This named_point class also inherits all the methods of the point class, which saves us from having to write them again (and maintain them).

A slot that was private or protected in a superclass may be defined as public. This will cause get and put methods to be generated in the subclass. A slot that was public in a superclass may be defined as protected or private, but this does not prevent it from inheriting the get and put methods of the superclass. For that, the uninherit/1 directive, defined below, is needed.