Tying Up Some Loose Strings
The two objects we have defined so far have included both double-quoted and single-quoted strings in their property definitions. To the seasoned TADS 2 programmer the distinction will need little further explanation. An author coming from Inform will be partly prepared and partly misled by the way in which single and double-quoted strings work in that language. Other readers may be totally mystified. At least a brief attempt at explanation is due at this point, since the distinction is fairly basic to TADS programming.
As a first approximation, a single-quoted string is simply a string constant, whereas a double-quoted string is a shorthand form of a statement that displays the string. That is to say the statement
|
"To err is human; to make a total mess-up requires a computer. ";
|
|
|
say('To err is human; to make a total mess-up requires a computer. ');
|
|
The main confusion comes about because a definition such as
|
desc = "It's a brass widget"
;
|
|
|
|
desc { say('It\'s a brass widget'); }
|
|
The difference in the way the two kinds of string are employed in object definitions is that single-quoted strings are generally used for single words or short phrases that will generally be displayed as part of a longer message (such as the name property), whereas a double-quoted string is generally used for properties that are expected to hold possibly quite lengthy text, usually one or more complete sentences, that will always be displayed just as they are (such as the full description of an object or room). One further key difference between single-quoted and double-quoted strings, and maybe the most important selection criterion in the library itself, is that the value of a single-quoted string can be inspected and manipulated, whereas a double-quoted string can really only be displayed. So, for example, if it's going to be necessary to look inside a string to see if it starts with a vowel, then we'll definitely want the single-quoted version.
As of TADS 3.1.0 both single and double-quoted strings may contain embedded expressions enclosed in double (<< >>). Such embedded expressions may evaluate to a number, a double-quoted string or a single-quoted string (or nothing at all, i.e. nil). This means that the statement
|
"The rain in Spain stays <<someExpression>> in the plain.";
|
|
|
say('The rain in Spain stays ' + someExpression + ' in the plain.');
|
|
|
|
"It's a <<metal>> widget. "
dobjFor(Take)
{
action()
{
name = 'silver widget';
metal = 'silver';
inherited;
}
}
metal = 'brass'
;
|
|
>x widget
It's a brass widget.
>take widget
Taken.
>x it
It's a silver widget.
>i
You are carrying a silver widget.
|
And one final point overall. You may have noticed that the above example used something called dobjFor(Take) followed by a method called action() enclosed within outer braces. If you followed the goldskull example in the previous chapter, you might have expected to see a method called actionDobjTake() here. In fact, the two ways of doing it are exactly equivalent. Technically, dobjFor(Take) is a macro, which the preprocessor expands into the code the compiler actually sees. The effect in this case is that what the compiler actually sees here is a method called actionDobjTake, exactly as before. Although a macro is usually meant to be a kind of shortcut, while in this case it actually makes the code a little more verbose, the use of the dobjFor and iobjFor macros in TADS 3 programming is so common that this is the style we shall follow from now on.
Getting Started in TADS 3
[Main]
[Previous] [Next]