Section 20.1. Resolution of Terminology

20.1. Resolution of Terminology

Example 20-1 exhibits some common patterns of terminology usage. With it, we'll model AppleScript's interaction with dictionaries during the process of compilation.

Example 20-1. Simple terminology resolution

 tell application "Finder"     set c to display dialog ((count folders) as string) end tell

Compilation of code like Example 20-1 proceeds in two distinct stages:

1. The tell block causes AppleScript to locate a particular application and load its dictionary.

2. The terms inside the tell block are resolved.

Let's consider these stages one at a time.

20.1.1. Loading the Dictionary

As AppleScript's compiler encounters a tell block (or a terms block) targeting a literal application, it attempts to locate this application and load its dictionary. If the compiler can't find the application, it will ask the user where it is; if the user cancels out of this process, refusing to choose an application, AppleScript will not compile the script (see "Missing External Referents" in Chapter 3).

AppleScript will proceed happily at this point, provided that it can find the application, or the user chooses an application for itany application. The compiler has not yet reached the stage of trying to resolve any actual terminology, so it doesn't matter whether there is any terminology to resolve, or even whether the application has a dictionary. All that matters so far is that the application referred to in code should be identified with some actual application.

Loading a dictionary takes time, and may even require launching the application in question, which takes even more time. Once the current instance of the AppleScript scripting component has already loaded a particular application's dictionary, however, it doesn't need to do so again, because it now has a copy of the dictionary cached in memory. These are some of the reasons why a script typically takes longer to compile the first time.

20.1.2. Translating the Terms

Presume that the compiler has reached the interior of the innermost tell block or terms block that caused a dictionary to be loaded. The compiler now proceeds to resolve the actual terms of the block.

20.1.2.1. The innermost application dictionary

Only one application dictionary is involved in the resolution of terminology in a given context. This is the dictionary corresponding to the innermost surrounding terms block or tell block where an application is explicitly specified. Let's call this the innermost application dictionary .

The interaction between nested terms blocks and tell blocks in determining the target and the innermost application dictionary was described in Chapter 11 and Chapter 19. Recall that iTunes is not targeted in this code:

 tell application "iTunes"     tell application "Finder"         count folders     end tell end tell

So iTunes's dictionary will be loaded at compile time (and this will necessitate launching iTunes if it isn't running already) but it will not be consulted because it isn't targeted. iTunes knows nothing of folders, but this doesn't matter. On the other hand, it does matter in a case like this:

 tell application "Finder"     using terms from application "iTunes"         count folders -- error: The variable folders is not defined     end using terms from end tell

The terms block deliberately perverts AppleScript's use of dictionaries. AppleScript, instructed explicitly to look in iTunes's dictionary, never learns that folder is defined in the Finder's dictionary, nor does it find folder in iTunes's dictionary. Thus it thinks folders is the name of a variable; that variable is undefined at runtime, causing an error.

20.1.2.2. Hunting for each term

Every term used in a given context must be found in a dictionary in order to be resolved. But the innermost application dictionary is not the only place where AppleScript may have to look, because some of the terms may be defined elsewhere. The hunt for terminology thus involves several steps. Here's how it goes:

1. The commands get and set (and sometimes copy) are specially short-circuited and are not sought in any dictionary.

2. The term is sought in the innermost application dictionary. (But see "No Terminology Clash," later in this chapter.)

3. The term is sought in AppleScript's own dictionary (described later in this chapter, under "The 'aeut' Resource").

4. The term is sought in the dictionaries of any scripting additions that are present.

5. The term is sought in the script itself.

Let's trace the resolution of the terms in Example 20-1, according to these rules:

• The term set (and its parameter to) are short-circuited (rule 1).

• The term folder is defined in the Finder's dictionary (rule 2).

• The term count appears both in the Finder's dictionary and in AppleScript's own dictionary. The former is used in the present case (rule 2).

• The term string appears in AppleScript's own dictionary (rule 3).

• The term display dialog is defined in a scripting addition's dictionary (rule 4).

• The term c isn't found anywhere, so it's sought in the script, and is resolved as the name of an implicitly defined local variable (rule 5).

As part of the terminology resolution process, AppleScript translates terms into their corresponding four-letter codes and constructs any Apple events that are called for (Chapter 3). So in Example 20-1, the Finder defines folder as 'cfol' and count as 'core\cnte', and AppleScript constructs this Apple event:

 core\cnte {     kocl:'cfol',     ----:'null'( ) }

The Apple event is written into the compiled code, ready to be sent to the Finder at runtime.