When the system loads a class, it iteratively loads all methods used by the class.

Before loading a class, the system checks the definitions of the superclasses to ensure that they allow the methods to be loaded directly. However, the methods in the class might need recompiling if one of the following conditions is true:

If the class edition you are loading has a different definition than the currently loaded edition, then instances of that class in your image change to the new representation. If this occurs, the system erases variables that have been removed. Any objects which the variables referenced are then subject to garbage collection as usual. New variables are set to nil.

When recompilation is necessary, compile errors are possible. If a method cannot be recompiled, either the load is canceled or a new edition of the class is created (and the offending method is removed from the new edition). If the user is not allowed to create a new class edition, the load is canceled. You can also control whether the load is canceled or continues by evaluating a preference. For example, to always cancel the load, evaluate the following:

A method collision is a state where the same method is being added to a class by more than one application. A preference tells the image what to do in case of a method collision. For example, to tell the image to always cancel the load in case of a method collision, evaluate this expression:

If the above preference is set to false, and the class can be changed, then the edition of the method which is loaded is the one in the application that is the lowest in the application hierarchy. All other implementations of the method are deleted from the other applications.