8.1 Initial Capabilities

Note that this section is quite likely to vary depending on the design of the specific MOZ in question. What is described here is simply from the perspective of the base MOZ server.

In general, a created object should be passed, as an init argument, the smallest number of capabilities possible. At a minimum, this consists of the following:

• A list of capabilities on the Storage object, so that new objects can be created. This would include a way to list class names as well as a direct object creation call.
• A class testing capability from the Storage object. This takes an object reference and returns true if and only if the object in question is an instance of one of the built-in or otherwise judged safe Oz classes. This is used to warn players that they might be in trouble if they go into, say, rooms of other classes. Note that Wizards can add to this list, and should only do so if they've read the code in question.
• A listContents capability on the room the object is created in. Note that this returns a list of requestCapability capabilities on the contents, i.e. a set of functions that can be used to ask for other capabilities
• A listExits capability on the room the object is created in.
• A requestCapability capability on the room the object is created in.

That's a pretty short list, but it is actually quite sufficient, as we'll see in the next section. Note that this glosses over some issues, like the capabilities shared between the Player, Parser, and Connection objects, but that's a little low level for this discussion.

Note that the requestCapability capability on the starting room allows the object to get the other capabilities on the starting room that it starts with; they are provided initially simply to save time.