Multiple-Word Terms

Many terms, especially commands in scripting additions, consist of multiple words . An example frequently used in this book is display dialog. You might think that such a term would present extra challenges for resolution, but in actual fact just the opposite appears to be the case; multiple-word terms are a good thing:

You can't make one

Terms that you create in a script can't contain spaces unless surrounded by pipes—and pipes mean that no dictionary will be consulted. Therefore the probability of your creating a term in a script that clashes with a dictionary-based multiple-word term is zero.

Clash is improbable

The more words a term consists of, the more likely it is that this term is unique among all dictionaries. This is especially important with scripting additions, whose terms are globally visible; for this reason, well-behaved scripting additions tend to use multiple-word commands.

There is no clash with single-word terms

This is the really surprising part. Consider, for example, the scripting addition command set the clipboard to. Even though set...to is a command, and the is usually ignored, and clipboard could be a variable name (and is in fact a property defined by AppleScript), no confusion arises:

local clipboard, tester
set clipboard to "Mannie" -- sets the variable clipboard
set the tester to "Moe" -- sets the variable tester (ignoring "the")
set the clipboard to "Jack" --sets the system scrap

Though I don't know the details, a natural explanation of AppleScript's success in resolving multiple-word terms would be that it tries the longest possible combinations of words first.

A multiple-word property name can be a little troublesome. The most commonly encountered example is text item delimiters (Chapter 16). Here's what happens when you use this term in a tell block targeting a scriptable application:

tell application "Finder"
    get text item delimiters -- error: Finder got an error: Can't get text item delimiters
end tell

In that code, AppleScript successfully resolves text item delimiters as the 'txdl' property, but then it makes a mistake: it sends an Apple event to the Finder, asking for this property. The Finder has no 'txdl' property, so it returns an error. The usual workaround is to add my or AppleScript's:

tell application "Finder"
    get my text item delimiters -- fine
end tell

But no Apple event is sent to the Finder in the case of a one-word global property:

tell application "Finder"
    get space
end tell

I believe this is the same behavior discussed in "No Terminology Clash," earlier in this chapter: space is a name already in scope, and we don't say this is the Finder's space, so it is assumed to be our space (meaning AppleScript's space). Evidently this rule breaks down with multiple-word properties. Fortunately, multiple-word properties that you might be tempted to use unqualified (without saying of something) are very rare—indeed, text item delimiters is probably the only one.