14: Declaring Class IDs, Characteristics, and Inheritance

1. Specifying a class identifier
   1. You can't use a class ID already used in the module unless this class definition is backward compatible with the class already defined.
   2. If you use a built-in class identifier for a custom class, the built-in class will predominate so your class definition will have no meaning.
   3. If you use the class identifier of an imported class, your class will override the imported class and will be used in any other class definitions within the module that use that class in their definition.
2. Declaring a sealed class
   1. Use the "sealed" keyword.
   2. Sealing a class insures that no subclasses can be defined.
   3. You may see built-in subclasses of a sealed built-in class; built-ins can override the sealed class, but you can't. Sealing a class prohibits add-on subclasses.
   4. If you don't want to seal an entire class, you can seal individual features within the class (as described later).
3. Declaring an abstract class
   1. Use the "abstract" keyword.
   2. An abstract class can't be instantiated; it's useful as a conceptual class used to create instantiable subclasses.
   3. You cannot declare an abstract class as a mix-in class because mix-ins are abstract by definition. Only flavors may be declared abstract classes.
4. Declaring a mix-in class
   1. Use the "mix-in" keyword.
   2. A mix-in class cannot be an abstract class.
   3. A class not declared as a mix-in class is a flavor.
5. Listing superclasses
   1. For a flavor
      1. The first class in the list must be a flavor.
      2. There can be no more than one flavor in the class list.
      3. If no superclasses are listed, the single superclass "Object" is set by default.
   2. For a mix-in
      1. The first class in the list may be a flavor or a mix-in.
         1. This class is the mix-in's anchor. An anchor class is the class (flavor or mix-in) with which the mix-in can be used. Specifying an anchor means the mix-in can be used only with that anchor class and any subclasses derived from that anchor class
      2. There can be no more than one anchor in the class list.
      3. If no anchor is listed, the anchor is set to Object.
   3. The order in which classes are listed in the superclasses list determines the canonical order of the superclasses, the order used to search for a method to execute and the order used in initialization escalation (both explained in later chapters).
   4. The superclasses listed are interface superclasses. They also define the implementation superclasses if needed.

Generated by the sweat of Mike Boom's brow.