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:
|
Mix-in |
Derived From |
|
Roomable |
RoomActionable,
RoomDisplayable, RoomTravelable |
|
DarkRoomable |
DarkRoomActionable, DarkRoomDisplayable,
DarkRoomTravelable |
|
NestedRoomable |
NestedRoomActionable,
NestedRoomDisplayable, NestedRoomTravelable |
|
Vehicular |
NestedRoomDisplayable,
VehicularActionable, VehicularTravelable |
|
Chairable |
ChairActionable, ChairDisplayable,
ChairTravelable |
|
Bedable |
BedActionable, ChairDisplayable,
ChairTravelable |
|
Enterable |
EnterableActionable,
EnterableDisplayable, EnterableTravelable |
Interfaces
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.