This is README.rtf in view mode; [Download] [Up]
MOKit docs, Copyright ©1992, 1993, 1994 by Mike Ferris. All Rights Reserved. By Mike Ferris -- October 23rd, 1993 MOKit Bundles The Bundles directory is full of bundles containing one MOKit class each which are used in MOKit palettes. Unless you are making new palettes or adding new objects to the kit which will use other kit objects, you should not have to use these bundles. Most users of MOKit will simply link their apps against the MOKit library. All MOKit palettes include only the palette and any inspector objects in the palette binary. Even the object that is supposed to be on the palette is loaded dynamically by the palette at startup time. The reason for this is that more than one palette might include objects of the same MOKit class. Also, note that MOKit classes which use other MOKit classes use them indirectly and will attempt to load the classes they depend on if they are not already available in the runtime system. For instance: The MORegexFormCell class uses MOStrings in its implementation, but it does not allocate MOStrings like one normally would (ie [MOString alloc]). MORegexFormCell has an static class variable call MOStringClass. In MORegexFormCell's +initialize method, objc_lookUpClass() is used to look up the class object for MOString, and if it isn't there, an attempt is made to find a MOString bundle and load the class dynamically. Once the class has been loaded and looked up, the static variable MOStringClass is used instead of the usual global MOString symbol where the MOString class object is needed. Now MORegexTextCell does the same thing. Even though both MORegexFormCell and MORegexTextCell use MOString, they could be on different IB palettes and still work because the MOString class will not be in either palette's binary. But the MOString bundle will be in both, and the first palette to load will load the MOString class. The second palette will just find MOString already there and use it instead of attempting to load its own bundle. The same thing goes for two palettes that both use MORegexFormCell. Since neither palette has the class linked into its binary, the first palette to be loaded will load the MORegexFormCell class, and if another palette that uses the class is loaded later, it will just use the class already loaded. Without some scheme like this, the palettes can easily collide when the dynamic linker tries to load an object file with an object that is already loaded in it. NOTE: When MOKit classes need another class for their implementation, they follow these steps: 1) If the needed class is already loaded, they use that 2) If the class bundle can be found in the "main" bundle, it is loaded 3) If the class bundle can be found in the "class" bundle it is loaded In the normal case, the main bundle and the class bundle are the same. Now this strategy does not work for classes loaded from bundles by a palette since the logical place to put these bundles is in the palette bundle. So in this case, the palette should insure that any classes needed by other classes that the palette dynamically loads, are loaded first. For example, in the MORegexPalette, all the cell classes make use of MOString. Therefore, it is important for the MORegexPalette class to load MOString first in its initialize method before the cell classes get loaded. All this is easier to understand if you look at the MORegexPalette and the classes it uses for what's going on.
These are the contents of the former NiCE NeXT User Group NeXTSTEP/OpenStep software archive, currently hosted by Netfuture.ch.