Assert

MultiMorphic

User

Guide

Version 1.0

This file is part of the TADS 3 Morphic Library Extension

What is MultiMorphic?

The MultiMorphic class gives the illusion of dynamically-defining its superclass list during runtime. A MultiMorphic class object can thus change its states and behaviors at runtime by altering its superclass list, something a normal object cannot do. A Surface can become a Container; an Actor can become a Thing; simply by changing the objects in a MultiMorphic’s defaultHandler list.

Defining a MultiMorphic

While the definition of MultiMorphic carries out its charade effectively, according to information provided by the object’s reflection methods, the VM is not fooled. It’s therefore necessary to make use of propNotDefined() as part of the MultiMorphic definition. It’s also necessary to override the inherited() keyword, so that the integrity of the MultiMorphic inheritance illusion is maintained.

Defining a MultiMorphic is easy. To do so, you must:

#include the multi_morphic.h header file in the library’s adv3.h header file. It is necessary to #include this file in every source module that contains the inherited() keyword, especially those that contain game object definitions. Since adv3.h is already #included in these files, The #include of multi_morphic.h in the adv3.h header accomplishes this. The multi_morphic.h header also defines the MultiMorphic template, making it as easy to define a MultiMorphic as any Thing class object. To simplify this process, remove adv3.h from the include list, and point to the adv3.h provided by multimorphic.
Next, the multi_morphic.t file must be included after the TADS 3 library in the compilation list. This module modifies Object to define useful methods for determining an object’s inheritance order, as well as a method to simulate inherited(). The module also defines the MultiMorphic class.

Now the library prerequisites have been setup. You need only define the multimorphic object itself. Suppose you want to define a LockableContainer. You could do this as follows:

+ metalBox: MultiMorphic

{

‘metal box’ ‘metal box’

defaultHandler = [Lockable, OpenableContainer]

}

After compilation, we can explore the object:

Welcome to the TADS 3 Starter Game!

Entryway

This large, formal entryway is slightly intimidating: the walls are lined with somber portraits of gray-haired men from decades past; a medieval suit of armor, posed with a battle axe at the ready, towers over a single straight-backed wooden chair. The front door leads back outside to the south. A hallway leads north.

You see a metal box here.

>x box

It's closed.

>open it

Opened.

>lock it

(first closing the metal box)

Locked.

Caveats of the MultiMorphic

MultiMorphic is only one mechanism for simulating dynamic superclass definition, and it is not without a few dangers. The most apparent of these are broken flow of inheritance and infinite loops.

The model simulates the TADS 3 inherited() keyword, and requires that every module that define objects used as superclasses override this keyword with the macro defined in multi_morphic.h. Modules that do not override inherited() will not be able to follow the inheritance order of MultiMorphic objects.
Additionally, because the overriding definition makes use of propInherited() it is possible to get into an infinite loop if an override of propInherited() invokes inherited(). The basic definition of the simulation algorithm does not provide for this possibility.
Use of inherited() within the definition of MultiMorphic itself may cause infinite loop problems, especially for intrinsic methods such as getSuperclassList(). This is because the MultiMorphic object’s inheritance order list is built using these intrinsic class methods. Therefore it is best not to override these methods.
The MultiMorphic class itself does not appear in a multimorphic’s superclass list. This is because including the class in getSuperclassList() results in an infinite loop when the object’s inheritance order list is being constructed.

There may be other hazards of the MultiMorphic as well, and use of this object definition should be viewed as an abuse of TADS 3, that is, outside the normal bounds of the general purpose and function of the language and library.

Nevertheless, MultiMorphic also demonstrates the power and flexibility of TADS 3, in that dynamic superclass list simulation is relatively simple to implement, and within certain restrictions, relatively stable.

This file is part of the TADS 3 MultiMorphic Library Extension