Objects and classes are stored in files, and must be stably accessible between invocations of moz. Therefore objects and classes must have static names which are used to refer to them by other objects within the MOZ, and there must be associations between those names and the objects themselves (well, the active object wrappers really, see The Active Object Wrapper), as well as between the file names the objects are stored in and their MOz names (or the objects themselves). All these mappings should be two-way, but mappings cannot be made on procedures or objects or classes, so in some cases large searches must be performed. Oh well.
Since class Storage is in the best position to obtain this information, and it has nothing else to do after startup anyways except swap objects to and from disk and answer capability questions, associations will be stored on the MOZs Storage object.
As can be seen in the MozBase def, all objects have a stateless NewName
associated with them, which is set at object creation using a name
created by Storage, and passed to init on the object. class Storage
has a dictionary to associate this name with the actual objects:
'oznameObj'.
Since there's no real point worrying about making up file names for objects, and since I'd like to not require uniqueness of object 'names' (distinct from the Oz-level name for the object), I decided to just have the object files be named with incremental integers with a .obj suffix. A dictionary 'fileOzName' associates these integers with the unique object names. It would have been an array, but arrays in Oz can't grow without rather a lot of work. A dictionary 'oznameFile' provides the reverse mapping.
Objects are stored as records (using toRecord and fromRecord). One of
the things that is in those lists is the class identifier, which we
might as well have be a name. That name must be unique. The file name
the classes are stored in is just that name with a .class suffix. The
file does _not_ store a pickle of the class: it stores the actual source
of the class. Otherwise it would be very difficult to present users
with the source of classes, since Oz does not appear to have a
decompilation feature.
The association between class names and the classes themselves are handled by the dictionary 'nameToClass'.
It is useful in the extreme to store on Storage what class each object belongs to, so that we can certify objects as being instantiations of a known-safe class. So, at load time and during upgrades the class of any given object is store in the dictionary 'oznameToClassName'.
Also, for wizardly purposes it is necessary for the Storage object to store a list of the capabilities available on each object in the MOZ. This are updated at load and upgrade time, and are stored in the dictionary 'oznameToCapabilities'.
It would be incredibly inneficient to actually trace these dictionaries
for every call to every method not on the local object, and it would
make things much more complicated when dealing with objects from another
MOZ See R1, so these associations are, for the most part, only used
at load and save time. toRecord, fromRecord and upgrade use these
assocations, and that's pretty much it, except for Wizardly usage, which
is not discussed here.