Should we automatically unlock this door on OPEN? By default, we do this only if the lock status is obvious.

Our initial locked state (i.e., at the start of the game). By default, we start out locked.

Internal locked state. Do not use this to set the initial state - set initiallyLocked in the master object instead.

Description of the object's current locked state. In English, this simply returns one of 'locked' or 'unlocked'. (Note that this is provided as a convenience to games, for generating messages about the object that include its state. The library doesn't use this message itself, so overriding this won't change any library messages - in particular, it won't change the examineStatus message.)

Is our 'locked' status obvious? This should be set to true for an object whose locked/unlocked status can be visually observed, nil for an object whose status is not visuall apparent. For example, you can usually tell from the inside that a door is locked by looking at the position of the lock's paddle, but on the outside of a door there's usually no way to see the status.

By default, since we can be locked and unlocked with simple LOCK and UNLOCK commands, we assume the status is as obvious as the mechanism must be to allow such simple commands.

Is our 'locked' status reportable in our current state? This is similar to lockStatusObvious, but serves a separate purpose: this tells us if we wish to report the lock status for aesthetic reasons.

This property is primarily of interest to mix-ins. To allow mix-ins to get a say, regardless of the order of superclasses, we'll by default defer to any inherited value if there is in fact an inherited value. If there's no inherited value, we'll simply return true.

We use this in the library for one case in particular: when we're mixed with Openable, we don't want to report the lock status for an open object because an Openable must by default be closed to be locked. That is, when an Openable is open, it's always unlocked, so reporting that it's unlocked is essentially redundant information.

"lock"

"lock with"

A locked object can't be opened - apply a precondition and a check for "open" that ensures that we unlock this object before we can open it.

If the lock status isn't obvious, don't try to unlock the object as a precondition. Instead, test to make sure it's unlocked in the 'check' routine, and fail.

"unlock"

"unlock with"

show our status

initialization

Current locked state. Use our isLocked_ status if we're the master, otherwise defer to the master.

Make the object locked or unlocked. Objects can override this to apply side effects of locking or unlocking. By default, if we're the master, we'll simply set our isLocked_ property to the new status, and otherwise defer to the master object.