0.5 - The Registry: The beginning of the end

Submitted by Trispis on Fri, 2006-09-15 04:21

The REGISTRY

See the comments below this page.

As indicated in several places throughout this document, the WARPEDcore is intended to serve as a registry for any and/or all of your global objects ($command globals in the Master Room, as well as global @function objects). This section covers the procedures and standards for registering such objects, and lists any reserved module names (intended solely for standardization purposes).

  1. Attribute Names

    As indicated in the section on attribute naming conventions, the WARPEDcore is intended to record the #dbrefs of your globals and other key objects of your game. This is accomplished by storing said #dbrefs in attributes on the WARPEDcore itself, using a special attribute naming convention. When registering an object, the following guidelines must be observed.

    1. The attribute name must begin with DB_, followed by the registered module name
    2. The module name, if it isn't completely obvious, should be representative of the object being registered.
    3. Any characters allowed in an attribute name are allowed in a module name. However, it is recommended that the dot (.), the tilde (~), and the underscore (_) not be used as the first character, and that the underscore (_) be used in place of a literal space.
    4. Examples:

    • DB_BBOARD
    • DB_MYRDDINS_BBOARD
    • DB_PLACES-MUTTER
  • Attribute Contents

    The registry attributes (those beginning with DB_) only contain #dbrefs. Furthermore, the #dbrefs stored in these attributes should be efficiently kept to a minimum. When registering a module, only register the lowest 'child' #dbrefs of any parented systems. Furthermore, do not register objects which are spontaneously created by other registered #dbrefs. Some examples...

    • DB_MYRDDINS_BBOARD would contain only the #dbref for the main $command object. The "bbpocket" object would not be registered, since that object is the parent of the main command object (and thus, implicitly included already). Likewise, none of the #dbrefs for the individual bboard group objects should be listed either, as they are subject to spontaneous creation and destruction by the main object.
    • DB_ACTIVITY The +activity global on M*U*S*H (although not yet a publicly released package, it is hoped that it someday will be -- nevertheless, it is still a register-able module) has a $command object parented to a functions object, a timed processes object, and 8 databases (one for each day of the week, and one for the week as a whole). This module would register the $command object first, followed by the triggered processes object. The 8 database #dbrefs could optionally be registered, but the fact that they are located in the contents of the triggered processes object might be sufficient in itself -- this is a subjective call, based on coder preference. It would not, however, list the functions object, because it is a parent to one of the other objects. In all, this attribute could conceivably contain two (2) or ten (10) #dbrefs.
  • Reserved Module Names

    The following module names (in the form of attribute names) have been reserved in an effort to promote standardization growth.

    • DB_MORT_CMND_FOR_MORT
    • DB_ROY_CMND_FOR_MORT
    • DB_WIZ_CMND_FOR_MORT
    • DB_MORT_CMND_FOR_ROY
    • DB_ROY_CMND_FOR_ROY
    • DB_WIZ_CMND_FOR_ROY
    • DB_MORT_CMND_FOR_WIZ
    • DB_ROY_CMND_FOR_WIZ
    • DB_WIZ_CMND_FOR_WIZ
    • DB_MORT_FUNC
    • DB_ROY_FUNC
    • DB_WIZ_FUNC

    These reserved names will allow installation packages to locate the appropriate objects for writing their attributes, rather than creating a new object.