(updated April 2000)
Modules are subclasses of MesquiteModule, which in turn is a subclass of EmployerEmployee, which in turn is a subclass of MenuOwner. The latter two classes are not intended to be used for anything else other than to serve as superclasses for MesquiteModule. The reason the three classes are separated is to partition the many methods needed into natural groups that are smaller and more manageable. MenuOwner includes all of the many methods to added and manipulate menu items. EmployerEmployee contains the methods to deal with the employee-employer interactions among modules (hiring, firing, and so on). MesquiteModule itself contains methods dealing with other issues. We will speak of all of these methods as if they belonged to the MesquiteModule class.
Note: for MesquiteModules to be used in the system of employees and employers, they should not be instantiated directly. Instantiation is handled automatically by methods of EmployerEmployee when hireEmployee, hireCompatibleEmployee, or replaceEmployee is called. Consequently, subclasses of MesquiteModule do not need and should not have constructors. Instead, the equivalent of a constructor is the startJob method, which is called whenever a module is instantiated for use.
Some of the basic methods of MesquiteModule are the following. The methods underlined are built-in and you won't need to override them. For the other methods to be useful to you, you will need to override them.
To be useful, modules must subclass the duty classes which are subclasses of MesquiteModule. Each duty class promises to perform a particular set of functions.
A more complete description of Mesquite's modularity is given under architecture.
To learn how to write a Mesquite module see Making Modules.