The TADS Alternate Library
Version 2.0

Marker, Mix-in and Interface Classes

Copyright 2000 by Kevin Forchione.
This is part of the TADS Alternate Library Authors Manual.

Introduction and Table of Contents

Alt divides the library into classes, functions, grammar, and objects. Additionally classes are further broken down into Marker classes, Mix-in classes, and Interfaces as well as classes used to define game objects and classes that provide useful functionality.


Marker Classes


Marker classes are derived from object and are completely dependent upon the library for their behaviours. Other methods and functions use Marker classes but these classes do not define any special behaviour themselves. These classes should be listed last in the superclass list.


Alt defines 1 Marker classes: Hidden.


Mix-in Classes


These classes are also derived from object and are meant to provide behaviour to a class without the conflict of multiple inheritances of Thing. The mix-in classes include Fixture, Floating, Openable, KeyedLockable, Lockable, Transparent, as well as the –displayable, -actionable, and –travelable classes listed below.





Additionally, mix-ins have been defined for common library behaviours, such as those in the following table:



Derived From


RoomActionable, RoomDisplayable, RoomTravelable


DarkRoomActionable, DarkRoomDisplayable, DarkRoomTravelable


NestedRoomActionable, NestedRoomDisplayable, NestedRoomTravelable


NestedRoomDisplayable, VehicularActionable, VehicularTravelable


ChairActionable, ChairDisplayable, ChairTravelable


BedActionable, ChairDisplayable, ChairTravelable


EnterableActionable, EnterableDisplayable, EnterableTravelable





When a Mix-in class’ behaviour requires the definition of methods that are also defined by Thing the opportunity for inheritance conflicts arise. The clearest example of this is the ClothingItem class, which derives from the Wearable mix-in and Item classes. Wearable only defines attributes and methods directly involving wearing and removing clothing, but other methods are also associated with putting on and removing clothes, such as doDrop() or doTake(). These methods do specific things when the object is being worn, and other things when the object is not. Because of this it is desirable to pass the method call to the next level of inheritance.


Because Wearable derives from object, however, there is no means of passing control. Wearable cannot then define these methods, the object that derives from Wearable must define them. Interfaces help insure that a class derived from a class requiring special method definitions does indeed define them.