Object Definitions

TADS programs are made mainly of objects.

An "object" is a data structure that groups together a set of data values, called properties, and functions, called methods. Each property and each method has a name, which is a symbol that you can use to refer to the property or method from within the program. An object also has one or more "superclasses" (also called "base" classes); the superclasses provide defaults for any properties and methods that the object doesn't itself define but one or more of the superclasses do.

An object can be either "static" or "dynamic." A static object is one that is defined directly in your program's source code; it exists throughout execution of the program. A dynamic object is one that is created in the course of the program's execution with the "new" operator; it comes into existence when created with "new," and exists only as long as it is referenced by any local variables or properties. Once a dynamic object is no longer referenced anywhere in the executing program, the system automatically deletes the object, since it can no longer be used for anything.

Most TADS programs define numerous static objects, because these objects encode the game world that the program implements. An object can represent a real-world object that the game simulates, or a component of a real-world object, or an entirely abstract programmatic entity.

Basic Object Definition Syntax

The most general way to define an object is like this:

 objectName : class1, class2, class3
 prop1 = val1
 prop2 = val2
 method1 ( arg1, arg2 ) { methodBody1 }
 method2 ( arg1, arg2, arg3 ) { methodBody2 }
 ;

The first line names the object, and defines its superclass list. An object must always have at least one superclass, but you can use the special class name "object" if you want a generic object that is not based on another object that your program defines. Note, however, that if you use "object" as the superclass, it must be the only superclass.

If you specify more than one superclass, the order of the classes determines the inheritance order. The first (left-most) superclass has precedence for inheritance, so any properties or methods that it defines effectively override the same properties and methods defined in subsequent superclasses.

Alternatively, you can write the same thing in a slightly different way, by enclosing the list of properties in braces:

 objectName : class1, class2, class3
 {
 prop1 = val1
 prop2 = val2
 method1 ( arg1, arg2 ) { methodBody1 }
 method2 ( arg1, arg2, arg3 ) { methodBody2 }
 }

When you use this alternative syntax, you must place the entire property list within the braces. A semicolon is not required at the end of the object definition using this syntax, because the closing brace unambiguously ends the definition. (It's legal to add a semicolon after the closing brace, though, because a semicolon by itself is always acceptable as an empty top-level statement.) You may optionally place a semicolon after each property definition; the compiler simply ignores any such semicolons, because it knows the property list doesn't end until the closing brace.

The two object definition formats – with braces or without – are identical in meaning; they differ only in appearance. You can use either format for any object; the compiler automatically recognizes which form you're using for each object.

The language allows the two formats purely for your convenience. Because of the wide range of objects and classes that adventure game programs tend to define, many objects tend to look better in one format or the other. Some authors might find that small objects composed mostly of data look less cluttered and more compact without the braces, while larger objects with lots of code benefit from the more visually structured appearance of the brace format. Other authors might simply prefer the brace format in all cases because it's similar to Java and C++ notation.

Property Sets

In some situations, you'll need to define a group of related properties and methods that share some common root name, and possibly some common parameters as well. This situation sometimes occurs, for example, when you're using a library that defines a naming convention for the methods that your code provides to handle the individual processing steps for an event: all of the methods pertain to different phases of the same event, so the library gives all of the methods a common portion to their names to help make it clear that they're related.

The compiler provides a short-hand syntax that makes it easier to define sets of properties with related names. The propertyset keyword introduces a group of property definitions, and specifies a pattern string that defines the naming convention. A propertyset pattern string looks like a regular symbol name enclosed in single quotes, except that it contains a single asterisk ("*"), which specifies where the non-common part of the name goes. Everything else in the string is the common part of the names of the properties in the set.

For example, suppose you're using a library that defines a set of method calls that process mouse clicks. All of the mouse click methods have a common root name of "onMouse," but then add a suffix for the individual method: onMouseDown, onMouseMove, onMouseUp. For this set of names, the pattern string would be 'onMouse*' - the asterisk at the end tells the compiler that the only part that differs from one property to another is at the end of the string.

After the propertyset keyword and the pattern string, you place a set of otherwise normal property definitions, enclosed in a set of braces to mark the bounds of the set. So, the general syntax for a property set is:

 propertyset 'patternal>Most TADS programs define numerous static objects, because
these objects encode the game world that the program implements. An object can represent a real-world object
that the game simulates, or a component of a real-world object, or an entirely
abstract programmatic entity.


Basic Object Definition Syntax

The most general way to define an object is like this:

 

 objectName : class1, class2, class3
 prop1 = val1
 prop2 = val2
 method1 ( arg1, arg2 ) { methodBody1 }
 method2 ( arg1, arg2, arg3 ) { methodBody2 }
 ;

 

The first line names the object, and
defines its superclass list. An object
must always have at least one superclass, but you can use the special class
name "object" if you want a generic object that is not based on
another object that your program defines. Note, however, that if you use "object" as the superclass, it
must be the only superclass.

 

If you specify more than one
superclass, the order of the classes determines the inheritance order. The first (left-most) superclass has
precedence for inheritance, so any properties or methods that it defines effectively
override the same properties and methods defined in subsequent superclasses.

 

Alternatively, you can write the same
thing in a slightly different way, by enclosing the list of properties in
braces:

 

 objectName : class1, class2, class3
 {
 prop1 = val1
 prop2 = val2
 method1 ( arg1, arg2 ) { methodBody1 }
 method2 ( arg1, arg2, arg3 ) { methodBody2 }
 }

 

When you use this alternative syntax,
you must place the entire property list within the braces. A semicolon is not required at the
end of the object definition using this syntax, because the closing brace
unambiguously ends the definition. (It's legal to add a semicolon after the closing brace, though, because
a semicolon by itself is always acceptable as an empty top-level
statement.) You may optionally place a
semicolon after each property definition; the compiler simply ignores any such
semicolons, because it knows the property list doesn't end until the closing
brace.

 

The two object definition formats –
with braces or without – are identical in meaning; they differ only in
appearance. You can use either format
for any object; the compiler automatically recognizes which form you're using
for each object.

 

The language allows the two formats
purely for your convenience. Because of
the wide range of objects and classes that adventure game programs tend to
define, many objects tend to look better in one format or the other. Some authors might find that small objects
composed mostly of data look less cluttered and more compact without the
braces, while larger objects with lots of code benefit from the more visually
structured appearance of the brace format. Other authors might simply prefer the brace format in all cases because
it's similar to Java and C++ notation.

Property
Sets

In some situations, you'll need to define a group of related
properties and methods that share some common root name, and possibly some
common parameters as well. This
situation sometimes occurs, for example, when you're using a library that
defines a naming convention for the methods that your code provides to handle
the individual processing steps for an event: all of the methods pertain to
different phases of the same event, so the library gives all of the methods a
common portion to their names to help make it clear that they're related.

 

The compiler provides a short-hand syntax that makes it
easier to define sets of properties with related names. The propertyset keyword
introduces a group of property definitions, and specifies a pattern string that
defines the naming convention. A
propertyset pattern string looks like a regular symbol name enclosed in single
quotes, except that it contains a single asterisk ("*"), which
specifies where the non-common part of the name goes. Everything else in the string is the common part of the names of
the properties in the set.

 

For example, suppose you're using a library that defines a
set of method calls that process mouse clicks. All of the mouse click methods have a common root name of
"onMouse," but then add a suffix for the individual method:
onMouseDown, onMouseMove, onMouseUp. For this set of names, the pattern string would be 'onMouse*' - the
asterisk at the end tells the compiler that the only part that differs from one
property to another is at the end of the string.

 

After the propertyset keyword and the
pattern string, you place a set of otherwise normal property definitions,
enclosed in a set of braces to mark the bounds of the set. So, the general syntax for a property set
is:

 

 propertyset 'patternal>Most TADS programs define numerous static objects, because
these objects encode the game world that the program implements. An object can represent a real-world object
that the game simulates, or a component of a real-world object, or an entirely
abstract programmatic entity.


Basic Object Definition Syntax

The most general way to define an object is like this:

 

 objectName : class1, class2, class3
 prop1 = val1
 prop2 = val2
 method1 ( arg1, arg2 ) { methodBody1 }
 method2 ( arg1, arg2, arg3 ) { methodBody2 }
 ;

 

The first line names the object, and
defines its superclass list. An object
must always have at least one superclass, but you can use the special class
name "object" if you want a generic object that is not based on
another object that your program defines. Note, however, that if you use "object" as the superclass, it
must be the only superclass.

 

If you specify more than one
superclass, the order of the classes determines the inheritance order. The first (left-most) superclass has
precedence for inheritance, so any properties or methods that it defines effectively
override the same properties and methods defined in subsequent superclasses.

 

Alternatively, you can write the same
thing in a slightly different way, by enclosing the list of properties in
braces:

 

 objectName : class1, class2, class3
 {
 prop1 = val1
 prop2 = val2
 method1 ( arg1, arg2 ) { methodBody1 }
 method2 ( arg1, arg2, arg3 ) { methodBody2 }
 }

 

When you use this alternative syntax,
you must place the entire property list within the braces. A semicolon is not required at the
end of the object definition using this syntax, because the closing brace
unambiguously ends the definition. (It's legal to add a semicolon after the closing brace, though, because
a semicolon by itself is always acceptable as an empty top-level
statement.) You may optionally place a
semicolon after each property definition; the compiler simply ignores any such
semicolons, because it knows the property list doesn't end until the closing
brace.

 

The two object definition formats –
with braces or without – are identical in meaning; they differ only in
appearance. You can use either format
for any object; the compiler automatically recognizes which form you're using
for each object.

 

The language allows the two formats
purely for your convenience. Because of
the wide range of objects and classes that adventure game programs tend to
define, many objects tend to look better in one format or the other. Some authors might find that small objects
composed mostly of data look less cluttered and more compact without the
braces, while larger objects with lots of code benefit from the more visually
structured appearance of the brace format. Other authors might simply prefer the brace format in all cases because
it's similar to Java and C++ notation.

Property
Sets

In some situations, you'll need to define a group of related
properties and methods that share some common root name, and possibly some
common parameters as well. This
situation sometimes occurs, for example, when you're using a library that
defines a naming convention for the methods that your code provides to handle
the individual processing steps for an event: all of the methods pertain to
different phases of the same event, so the library gives all of the methods a
common portion to their names to help make it clear that they're related.

 

The compiler provides a short-hand syntax that makes it
easier to define sets of properties with related names. The propertyset keyword
introduces a group of property definitions, and specifies a pattern string that
defines the naming convention. A
propertyset pattern string looks like a regular symbol name enclosed in single
quotes, except that it contains a single asterisk ("*"), which
specifies where the non-common part of the name goes. Everything else in the string is the common part of the names of
the properties in the set.

 

For example, suppose you're using a library that defines a
set of method calls that process mouse clicks. All of the mouse click methods have a common root name of
"onMouse," but then add a suffix for the individual method:
onMouseDown, onMouseMove, onMouseUp. For this set of names, the pattern string would be 'onMouse*' - the
asterisk at the end tells the compiler that the only part that differs from one
property to another is at the end of the string.

 

After the propertyset keyword and the
pattern string, you place a set of otherwise normal property definitions,
enclosed in a set of braces to mark the bounds of the set. So, the general syntax for a property set
is:

 

 propertyset 'patternal>Most TADS programs define numerous static objects, because
these objects encode the game world that the program implements. An object can represent a real-world object
that the game simulates, or a component of a real-world object, or an entirely
abstract programmatic entity.


Basic Object Definition Syntax

The most general way to define an object is like this:

 

 objectName : class1, class2, class3
 prop1 = val1
 prop2 = val2
 method1 ( arg1, arg2 ) { methodBody1 }
 method2 ( arg1, arg2, arg3 ) { methodBody2 }
 ;

 

The first line names the object, and
defines its superclass list. An object
must always have at least one superclass, but you can use the special class
name "object" if you want a generic object that is not based on
another object that your program defines. Note, however, that if you use "object" as the superclass, it
must be the only superclass.

 

If you specify more than one
superclass, the order of the classes determines the inheritance order. The first (left-most) superclass has
precedence for inheritance, so any properties or methods that it defines effectively
override the same properties and methods defined in subsequent superclasses.

 

Alternatively, you can write the same
thing in a slightly different way, by enclosing the list of properties in
braces:

 

 objectName : class1, class2, class3
 {
 prop1 = val1
 prop2 = val2
 method1 ( arg1, arg2 ) { methodBody1 }
 method2 ( arg1, arg2, arg3 ) { methodBody2 }
 }

 

When you use this alternative syntax,
you must place the entire property list within the braces. A semicolon is not required at the
end of the object definition using this syntax, because the closing brace
unambiguously ends the definition. (It's legal to add a semicolon after the closing brace, though, because
a semicolon by itself is always acceptable as an empty top-level
statement.) You may optionally place a
semicolon after each property definition; the compiler simply ignores any such
semicolons, because it knows the property list doesn't end until the closing
brace.

 

The two object definition formats –
with braces or without – are identical in meaning; they differ only in
appearance. You can use either format
for any object; the compiler automatically recognizes which form you're using
for each object.

 

The language allows the two formats
purely for your convenience. Because of
the wide range of objects and classes that adventure game programs tend to
define, many objects tend to look better in one format or the other. Some authors might find that small objects
composed mostly of data look less cluttered and more compact without the
braces, while larger objects with lots of code benefit from the more visually
structured appearance of the brace format. Other authors might simply prefer the brace format in all cases because
it's similar to Java and C++ notation.

Property
Sets

In some situations, you'll need to define a group of related
properties and methods that share some common root name, and possibly some
common parameters as well. This
situation sometimes occurs, for example, when you're using a library that
defines a naming convention for the methods that your code provides to handle
the individual processing steps for an event: all of the methods pertain to
different phases of the same event, so the library gives all of the methods a
common portion to their names to help make it clear that they're related.

 

The compiler provides a short-hand syntax that makes it
easier to define sets of properties with related names. The propertyset keyword
introduces a group of property definitions, and specifies a pattern string that
defines the naming convention. A
propertyset pattern string looks like a regular symbol name enclosed in single
quotes, except that it contains a single asterisk ("*"), which
specifies where the non-common part of the name goes. Everything else in the string is the common part of the names of
the properties in the set.

 

For example, suppose you're using a library that defines a
set of method calls that process mouse clicks. All of the mouse click methods have a common root name of
"onMouse," but then add a suffix for the individual method:
onMouseDown, onMouseMove, onMouseUp. For this set of names, the pattern string would be 'onMouse*' - the
asterisk at the end tells the compiler that the only part that differs from one
property to another is at the end of the string.

 

After the propertyset keyword and the
pattern string, you place a set of otherwise normal property definitions,
enclosed in a set of braces to mark the bounds of the set. So, the general syntax for a property set
is:

 

 propertyset 'patternal>Most TADS programs define numerous static objects, because
these objects encode the game world that the program implements. An object can represent a real-world object
that the game simulates, or a component of a real-world object, or an entirely
abstract programmatic entity.


Basic Object Definition Syntax

The most general way to define an object is like this:

 

 objectName : class1, class2, class3
 prop1 = val1
 prop2 = val2
 method1 ( arg1, arg2 ) { methodBody1 }
 method2 ( arg1, arg2, arg3 ) { methodBody2 }
 ;

 

The first line names the object, and
defines its superclass list. An object
must always have at least one superclass, but you can use the special class
name "object" if you want a generic object that is not based on
another object that your program defines. Note, however, that if you use "object" as the superclass, it
must be the only superclass.

 

If you specify more than one
superclass, the order of the classes determines the inheritance order. The first (left-most) superclass has
precedence for inheritance, so any properties or methods that it defines effectively
override the same properties and methods defined in subsequent superclasses.

 

Alternatively, you can write the same
thing in a slightly different way, by enclosing the list of properties in
braces:

 

 objectName : class1, class2, class3
 {
 prop1 = val1
 prop2 = val2
 method1 ( arg1, arg2 ) { methodBody1 }
 method2 ( arg1, arg2, arg3 ) { methodBody2 }
 }

 

When you use this alternative syntax,
you must place the entire property list within the braces. A semicolon is not required at the
end of the object definition using this syntax, because the closing brace
unambiguously ends the definition. (It's legal to add a semicolon after the closing brace, though, because
a semicolon by itself is always acceptable as an empty top-level
statement.) You may optionally place a
semicolon after each property definition; the compiler simply ignores any such
semicolons, because it knows the property list doesn't end until the closing
brace.

 

The two object definition formats –
with braces or without – are identical in meaning; they differ only in
appearance. You can use either format
for any object; the compiler automatically recognizes which form you're using
for each object.

 

The language allows the two formats
purely for your convenience. Because of
the wide range of objects and classes that adventure game programs tend to
define, many objects tend to look better in one format or the other. Some authors might find that small objects
composed mostly of data look less cluttered and more compact without the
braces, while larger objects with lots of code benefit from the more visually
structured appearance of the brace format. Other authors might simply prefer the brace format in all cases because
it's similar to Java and C++ notation.

Property
Sets

In some situations, you'll need to define a group of related
properties and methods that share some common root name, and possibly some
common parameters as well. This
situation sometimes occurs, for example, when you're using a library that
defines a naming convention for the methods that your code provides to handle
the individual processing steps for an event: all of the methods pertain to
different phases of the same event, so the library gives all of the methods a
common portion to their names to help make it clear that they're related.

 

The compiler provides a short-hand syntax that makes it
easier to define sets of properties with related names. The propertyset keyword
introduces a group of property definitions, and specifies a pattern string that
defines the naming convention. A
propertyset pattern string looks like a regular symbol name enclosed in single
quotes, except that it contains a single asterisk ("*"), which
specifies where the non-common part of the name goes. Everything else in the string is the common part of the names of
the properties in the set.

 

For example, suppose you're using a library that defines a
set of method calls that process mouse clicks. All of the mouse click methods have a common root name of
"onMouse," but then add a suffix for the individual method:
onMouseDown, onMouseMove, onMouseUp. For this set of names, the pattern string would be 'onMouse*' - the
asterisk at the end tells the compiler that the only part that differs from one
property to another is at the end of the string.

 

After the propertyset keyword and the
pattern string, you place a set of otherwise normal property definitions,
enclosed in a set of braces to mark the bounds of the set. So, the general syntax for a property set
is:

 

 propertyset 'patternal>Most TADS programs define numerous static objects, because
these objects encode the game world that the program implements. An object can represent a real-world object
that the game simulates, or a component of a real-world object, or an entirely
abstract programmatic entity.


Basic Object Definition Syntax

The most general way to define an object is like this:

 

 objectName : class1, class2, class3
 prop1 = val1
 prop2 = val2
 method1 ( arg1, arg2 ) { methodBody1 }
 method2 ( arg1, arg2, arg3 ) { methodBody2 }
 ;

 

The first line names the object, and
defines its superclass list. An object
must always have at least one superclass, but you can use the special class
name "object" if you want a generic object that is not based on
another object that your program defines. Note, however, that if you use "object" as the superclass, it
must be the only superclass.

 

If you specify more than one
superclass, the order of the classes determines the inheritance order. The first (left-most) superclass has
precedence for inheritance, so any properties or methods that it defines effectively
override the same properties and methods defined in subsequent superclasses.

 

Alternatively, you can write the same
thing in a slightly different way, by enclosing the list of properties in
braces:

 

 objectName : class1, class2, class3
 {
 prop1 = val1
 prop2 = val2
 method1 ( arg1, arg2 ) { methodBody1 }
 method2 ( arg1, arg2, arg3 ) { methodBody2 }
 }

 

When you use this alternative syntax,
you must place the entire property list within the braces. A semicolon is not required at the
end of the object definition using this syntax, because the closing brace
unambiguously ends the definition. (It's legal to add a semicolon after the closing brace, though, because
a semicolon by itself is always acceptable as an empty top-level
statement.) You may optionally place a
semicolon after each property definition; the compiler simply ignores any such
semicolons, because it knows the property list doesn't end until the closing
brace.

 

The two object definition formats –
with braces or without – are identical in meaning; they differ only in
appearance. You can use either format
for any object; the compiler automatically recognizes which form you're using
for each object.

 

The language allows the two formats
purely for your convenience. Because of
the wide range of objects and classes that adventure game programs tend to
define, many objects tend to look better in one format or the other. Some authors might find that small objects
composed mostly of data look less cluttered and more compact without the
braces, while larger objects with lots of code benefit from the more visually
structured appearance of the brace format. Other authors might simply prefer the brace format in all cases because
it's similar to Java and C++ notation.

Property
Sets

In some situations, you'll need to define a group of related
properties and methods that share some common root name, and possibly some
common parameters as well. This
situation sometimes occurs, for example, when you're using a library that
defines a naming convention for the methods that your code provides to handle
the individual processing steps for an event: all of the methods pertain to
different phases of the same event, so the library gives all of the methods a
common portion to their names to help make it clear that they're related.

 

The compiler provides a short-hand syntax that makes it
easier to define sets of properties with related names. The propertyset keyword
introduces a group of property definitions, and specifies a pattern string that
defines the naming convention. A
propertyset pattern string looks like a regular symbol name enclosed in single
quotes, except that it contains a single asterisk ("*"), which
specifies where the non-common part of the name goes. Everything else in the string is the common part of the names of
the properties in the set.

 

For example, suppose you're using a library that defines a
set of method calls that process mouse clicks. All of the mouse click methods have a common root name of
"onMouse," but then add a suffix for the individual method:
onMouseDown, onMouseMove, onMouseUp. For this set of names, the pattern string would be 'onMouse*' - the
asterisk at the end tells the compiler that the only part that differs from one
property to another is at the end of the string.

 

After the propertyset keyword and the
pattern string, you place a set of otherwise normal property definitions,
enclosed in a set of braces to mark the bounds of the set. So, the general syntax for a property set
is:

 

 propertyset 'patternal>Most TADS programs define numerous static objects, because
these objects encode the game world that the program implements. An object can represent a real-world object
that the game simulates, or a component of a real-world object, or an entirely
abstract programmatic entity.


Basic Object Definition Syntax

The most general way to define an object is like this:

 

 objectName : class1, class2, class3
 prop1 = val1
 prop2 = val2
 method1 ( arg1, arg2 ) { methodBody1 }
 method2 ( arg1, arg2, arg3 ) { methodBody2 }
 ;

 

The first line names the object, and
defines its superclass list. An object
must always have at least one superclass, but you can use the special class
name "object" if you want a generic object that is not based on
another object that your program defines. Note, however, that if you use "object" as the superclass, it
must be the only superclass.

 

If you specify more than one
superclass, the order of the classes determines the inheritance order. The first (left-most) superclass has
precedence for inheritance, so any properties or methods that it defines effectively
override the same properties and methods defined in subsequent superclasses.

 

Alternatively, you can write the same
thing in a slightly different way, by enclosing the list of properties in
braces:

 

 objectName : class1, class2, class3
 {
 prop1 = val1
 prop2 = val2
 method1 ( arg1, arg2 ) { methodBody1 }
 method2 ( arg1, arg2, arg3 ) { methodBody2 }
 }

 

When you use this alternative syntax,
you must place the entire property list within the braces. A semicolon is not required at the
end of the object definition using this syntax, because the closing brace
unambiguously ends the definition. (It's legal to add a semicolon after the closing brace, though, because
a semicolon by itself is always acceptable as an empty top-level
statement.) You may optionally place a
semicolon after each property definition; the compiler simply ignores any such
semicolons, because it knows the property list doesn't end until the closing
brace.

 

The two object definition formats –
with braces or without – are identical in meaning; they differ only in
appearance. You can use either format
for any object; the compiler automatically recognizes which form you're using
for each object.

 

The language allows the two formats
purely for your convenience. Because of
the wide range of objects and classes that adventure game programs tend to
define, many objects tend to look better in one format or the other. Some authors might find that small objects
composed mostly of data look less cluttered and more compact without the
braces, while larger objects with lots of code benefit from the more visually
structured appearance of the brace format. Other authors might simply prefer the brace format in all cases because
it's similar to Java and C++ notation.

Property
Sets

In some situations, you'll need to define a group of related
properties and methods that share some common root name, and possibly some
common parameters as well. This
situation sometimes occurs, for example, when you're using a library that
defines a naming convention for the methods that your code provides to handle
the individual processing steps for an event: all of the methods pertain to
different phases of the same event, so the library gives all of the methods a
common portion to their names to help make it clear that they're related.

 

The compiler provides a short-hand syntax that makes it
easier to define sets of properties with related names. The propertyset keyword
introduces a group of property definitions, and specifies a pattern string that
defines the naming convention. A
propertyset pattern string looks like a regular symbol name enclosed in single
quotes, except that it contains a single asterisk ("*"), which
specifies where the non-common part of the name goes. Everything else in the string is the common part of the names of
the properties in the set.

 

For example, suppose you're using a library that defines a
set of method calls that process mouse clicks. All of the mouse click methods have a common root name of
"onMouse," but then add a suffix for the individual method:
onMouseDown, onMouseMove, onMouseUp. For this set of names, the pattern string would be 'onMouse*' - the
asterisk at the end tells the compiler that the only part that differs from one
property to another is at the end of the string.

 

After the propertyset keyword and the
pattern string, you place a set of otherwise normal property definitions,
enclosed in a set of braces to mark the bounds of the set. So, the general syntax for a property set
is:

 

 propertyset 'patternal>Most TADS programs define numerous static objects, because
these objects encode the game world that the program implements. An object can represent a real-world object
that the game simulates, or a component of a real-world object, or an entirely
abstract programmatic entity.


Basic Object Definition Syntax

The most general way to define an object is like this:

 

 objectName : class1, class2, class3
 prop1 = val1
 prop2 = val2
 method1 ( arg1, arg2 ) { methodBody1 }
 method2 ( arg1, arg2, arg3 ) { methodBody2 }
 ;

 

The first line names the object, and
defines its superclass list. An object
must always have at least one superclass, but you can use the special class
name "object" if you want a generic object that is not based on
another object that your program defines. Note, however, that if you use "object" as the superclass, it
must be the only superclass.

 

If you specify more than one
superclass, the order of the classes determines the inheritance order. The first (left-most) superclass has
precedence for inheritance, so any properties or methods that it defines effectively
override the same properties and methods defined in subsequent superclasses.

 

Alternatively, you can write the same
thing in a slightly different way, by enclosing the list of properties in
braces:

 

 objectName : class1, class2, class3
 {
 prop1 = val1
 prop2 = val2
 method1 ( arg1, arg2 ) { methodBody1 }
 method2 ( arg1, arg2, arg3 ) { methodBody2 }
 }

 

When you use this alternative syntax,
you must place the entire property list within the braces. A semicolon is not required at the
end of the object definition using this syntax, because the closing brace
unambiguously ends the definition. (It's legal to add a semicolon after the closing brace, though, because
a semicolon by itself is always acceptable as an empty top-level
statement.) You may optionally place a
semicolon after each property definition; the compiler simply ignores any such
semicolons, because it knows the property list doesn't end until the closing
brace.

 

The two object definition formats –
with braces or without – are identical in meaning; they differ only in
appearance. You can use either format
for any object; the compiler automatically recognizes which form you're using
for each object.

 

The language allows the two formats
purely for your convenience. Because of
the wide range of objects and classes that adventure game programs tend to
define, many objects tend to look better in one format or the other. Some authors might find that small objects
composed mostly of data look less cluttered and more compact without the
braces, while larger objects with lots of code benefit from the more visually
structured appearance of the brace format. Other authors might simply prefer the brace format in all cases because
it's similar to Java and C++ notation.

Property
Sets

In some situations, you'll need to define a group of related
properties and methods that share some common root name, and possibly some
common parameters as well. This
situation sometimes occurs, for example, when you're using a library that
defines a naming convention for the methods that your code provides to handle
the individual processing steps for an event: all of the methods pertain to
different phases of the same event, so the library gives all of the methods a
common portion to their names to help make it clear that they're related.

 

The compiler provides a short-hand syntax that makes it
easier to define sets of properties with related names. The propertyset keyword
introduces a group of property definitions, and specifies a pattern string that
defines the naming convention. A
propertyset pattern string looks like a regular symbol name enclosed in single
quotes, except that it contains a single asterisk ("*"), which
specifies where the non-common part of the name goes. Everything else in the string is the common part of the names of
the properties in the set.

 

For example, suppose you're using a library that defines a
set of method calls that process mouse clicks. All of the mouse click methods have a common root name of
"onMouse," but then add a suffix for the individual method:
onMouseDown, onMouseMove, onMouseUp. For this set of names, the pattern string would be 'onMouse*' - the
asterisk at the end tells the compiler that the only part that differs from one
property to another is at the end of the string.

 

After the propertyset keyword and the
pattern string, you place a set of otherwise normal property definitions,
enclosed in a set of braces to mark the bounds of the set. So, the general syntax for a property set
is:

 

 propertyset 'patternal>Most TADS programs define numerous static objects, because
these objects encode the game world that the program implements. An object can represent a real-world object
that the game simulates, or a component of a real-world object, or an entirely
abstract programmatic entity.


Basic Object Definition Syntax

The most general way to define an object is like this:

 

 objectName : class1, class2, class3
 prop1 = val1
 prop2 = val2
 method1 ( arg1, arg2 ) { methodBody1 }
 method2 ( arg1, arg2, arg3 ) { methodBody2 }
 ;

 

The first line names the object, and
defines its superclass list. An object
must always have at least one superclass, but you can use the special class
name "object" if you want a generic object that is not based on
another object that your program defines. Note, however, that if you use "object" as the superclass, it
must be the only superclass.

 

If you specify more than one
superclass, the order of the classes determines the inheritance order. The first (left-most) superclass has
precedence for inheritance, so any properties or methods that it defines effectively
override the same properties and methods defined in subsequent superclasses.

 

Alternatively, you can write the same
thing in a slightly different way, by enclosing the list of properties in
braces:

 

 objectName : class1, class2, class3
 {
 prop1 = val1
 prop2 = val2
 method1 ( arg1, arg2 ) { methodBody1 }
 method2 ( arg1, arg2, arg3 ) { methodBody2 }
 }

 

When you use this alternative syntax,
you must place the entire property list within the braces. A semicolon is not required at the
end of the object definition using this syntax, because the closing brace
unambiguously ends the definition. (It's legal to add a semicolon after the closing brace, though, because
a semicolon by itself is always acceptable as an empty top-level
statement.) You may optionally place a
semicolon after each property definition; the compiler simply ignores any such
semicolons, because it knows the property list doesn't end until the closing
brace.

 

The two object definition formats –
with braces or without – are identical in meaning; they differ only in
appearance. You can use either format
for any object; the compiler automatically recognizes which form you're using
for each object.

 

The language allows the two formats
purely for your convenience. Because of
the wide range of objects and classes that adventure game programs tend to
define, many objects tend to look better in one format or the other. Some authors might find that small objects
composed mostly of data look less cluttered and more compact without the
braces, while larger objects with lots of code benefit from the more visually
structured appearance of the brace format. Other authors might simply prefer the brace format in all cases because
it's similar to Java and C++ notation.

Property
Sets

In some situations, you'll need to define a group of related
properties and methods that share some common root name, and possibly some
common parameters as well. This
situation sometimes occurs, for example, when you're using a library that
defines a naming convention for the methods that your code provides to handle
the individual processing steps for an event: all of the methods pertain to
different phases of the same event, so the library gives all of the methods a
common portion to their names to help make it clear that they're related.

 

The compiler provides a short-hand syntax that makes it
easier to define sets of properties with related names. The <