Lockable: a mix-in class that can be combined with an object's other superclasses to make the object respond to the verbs "lock" and "unlock." A Lockable requires no key.

Note that Lockable should usually go BEFORE a Thing-derived class in the superclass list.

class Lockable :   Linkable

Superclass Tree   (in declaration order)


Subclass Tree  


Global Objects  


Summary of Properties  

autoUnlockOnOpen  initiallyLocked  isLocked_  lockedDesc  lockStatusObvious  lockStatusReportable 

Summary of Methods  

dobjFor(Lock)  dobjFor(LockWith)  dobjFor(Open)  dobjFor(Unlock)  dobjFor(UnlockWith)  examineStatus  initializeThing  isLocked  makeLocked 

Inherited from Linkable :



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 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 with"

examineStatus ( )objects.t[3773]
show our status

initializeThing ( )OVERRIDDENobjects.t[3842]

isLocked ( )objects.t[3746]
Current locked state. Use our isLocked_ status if we're the master, otherwise defer to the master.

makeLocked (stat)objects.t[3760]
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.

TADS 3 Library Manual
Generated on 5/16/2013 from TADS version 3.1.3